While IRSA also let you connect pods to IAM roles, the added value is a number of optimizations: 1) With IRSA you had to make an OIDC endpoint to setup the trust relationship-now you don't have to make an OIDC endpoint and roles can be easily scoped to many clusters. 2) Cluster admins tend to not be the same admins that have privileged AWS IAM access-EKS Pod Identity means less back and forth. 3) Operators can setup EKS clusters in one step-with IRSA you had to wait for cluster to be "Ready" before configuring it.
Good afternoon! Very cool explanation, thank you. There is one problem with this approach: it often happens that more than one application works in the same namespace (for example, there can be more than one Deployment in the same namespace). Since Pod Identity assigns a Role that allows S3 access at the level of a particular namespace, this gives other Deployments and StatefulSets the ability to use this access, doesn't it?🤔 For now, it is better to create a service account in the old way and then hardcode it only to a specific Deployment. Alternatively, create a separate namespace for each Deployment so that access for one namespace is not used by other services as well. Correct me if I'm wrong about something. 🙏
Good question-Pod Identity works directly with service accounts within a namespace, so only the pods associated with the Kubernetes service account get the IAM permissions.
Very nice explanation. Thank you
听起来很不错，IRSA报错时的排查真的是好麻烦。而且对于pod的yaml定义应该也是友好的，从目前看，关键依然还是sa服务账号代表了真正的IAM权限。EKS团队确实做了很多工作，这个Pod identity 替代 IRSA， 访问条目替代 configmap aws-auth。越来越丰富的EKS console信息，这些确实进步很快。
Lovely video
It wasn’t clear what the added value of using eks pod identity was? Maybe it’s my misunderstanding, thanks in advance!
While IRSA also let you connect pods to IAM roles, the added value is a number of optimizations:
1) With IRSA you had to make an OIDC endpoint to setup the trust relationship-now you don't have to make an OIDC endpoint and roles can be easily scoped to many clusters.
2) Cluster admins tend to not be the same admins that have privileged AWS IAM access-EKS Pod Identity means less back and forth.
3) Operators can setup EKS clusters in one step-with IRSA you had to wait for cluster to be "Ready" before configuring it.
listen at the 3:46 mark
Good afternoon! Very cool explanation, thank you.
There is one problem with this approach: it often happens that more than one application works in the same namespace (for example, there can be more than one Deployment in the same namespace).
Since Pod Identity assigns a Role that allows S3 access at the level of a particular namespace, this gives other Deployments and StatefulSets the ability to use this access, doesn't it?🤔
For now, it is better to create a service account in the old way and then hardcode it only to a specific Deployment. Alternatively, create a separate namespace for each Deployment so that access for one namespace is not used by other services as well.
Correct me if I'm wrong about something. 🙏
Good question-Pod Identity works directly with service accounts within a namespace, so only the pods associated with the Kubernetes service account get the IAM permissions.
Does pod identity work with Fargate?
No