Hi All, We are using AWS EKS.
We are trying to use the new future of AWS, Service account level IAM.
The token for accessing AWS API is created in a projected volume and has only 600 permissions.
What is the difference between creating normal secrets and projected volume.
Also If a service account token volume is mounted as projected volume, will the token be automatically expire.?
Whether BoundServiceAccountTokenVolume is production ready.
As I understand from this article: https://aws.amazon.com/fr/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/ :
This permits to extend the RBAC functionality.
Traditionaly, you create a Service Account and runs a Pod with this serviceAccount, so the Pod inherits the rights given to this service Account (via Role, RoleBinding, ClusterRole, ClusterRoleBinding). This is the responsability of the API server to check that the Pod can access K8s resources.
By extension, AWS adds the ability to bind authorizations to AWS objects (S3, etc) to a Service Account, by linking an IAM role (AWS native role) to a service account (K8S native role), using the iamserviceaccount object.
But this time, the API server is not able to check the rights of the pod for the AWS resources. The applications in the containers of the pod needs to get an IAM token to access the AWS objects. This token is placed in the service account, and is mountable in the Pod via a projected Service Account Token.
Finally, the service token account is some equivalent of a Secret, but instead of manually mounting the Secret to each Pod you want give access to, you place the token in the Service Account, which will be accessible to all Pods running with this service account.
Thanks Feloy for the response, that clears my most of the doubts.
One last question, what is the main difference between mounting the service account token by creating secrets and mounting the service account token as projected volume.
The projected volume is to mount sources from various volumes into one directory. If you only have one source volume (the secret), there is no reason use projected volume.
Thanks rata for your reply.
So if we use projected volume for secrets and configmaps, we will still be having 2 different volumes for secret and configmap and they can be seen in a single directory.
Is my understanding correct?
Also if a service account is created as a normal secret instead of projected volume, we will not be able to mention the desired properties of the token, such as the audience and the validity duration.?
Yes.
Have you checked https://kubernetes.io/docs/concepts/storage/volumes/#projected ? There are some examples there too. But, of course, don’t hesitate to ask if it’s not clear 
Yes Rata, I have gone through this link.
We create service account and use the service account inside the pod. The service account has a token mounted in a volume to communicate with Kubernetes API, so using this way we can communicate with Kubernetes API. For example in the below case, if we add the below details to a pod, the pod will use the default token to communicate to Kubernetes API and the token mentioned below to call to the thirdparty(AWS)?
So by default, even if we mention projected volume, there will still be another default mount created for service account? I have seen in cases where audience: “api”, if this is kubernetes API, what will be the use of the default mount.
“mounting” a service account is a special case of mounting. You can mount a service account like you mount a configmap or a secret, but only via the projected feature (not directly like you would do with a secret or a configmap).
When you mount a service account, you find the token defined in your service account in your mount point in your container (in a similar way you would find the variables of a secret in your mount point).
To conclude, if you need to find your token in your mount point, you need to mount your service account, and you can only mount it via the projected feature.
Does this reply to your question?
