Role-Service Binding
Introduction
A permission is to used to attach the role to define what is the role used for
A trust relationship is essential when binding AWS IAM roles to Kubernetes service accounts. This relationship defines which entities (like services or users) are allowed to assume the IAM role.
The trust relationship bridges the gap between Kubernetes service accounts and AWS IAM roles, enabling seamless integration.
Kubernetes
Amazon EKS integrates OpenID Connect (OIDC) and IAM roles to enable Kubernetes pods to securely access AWS resources.
An IAM role is created with a trust policy that specifies the OIDC provider as the trusted entity. This policy includes conditions to ensure that only specific Kubernetes service accounts can assume the role.
When the pod make a request to service account, Kubernetes issues a token signed by the OIDC provider. This token contains claims, such as the service account name and namespace.
The pod presents the token to AWS STS (Security Token Service). AWS verifies the token against the OIDC provider and checks the trust policy of the IAM role. If the token is valid and matches the conditions in the trust policy, AWS allows the pod to assume the IAM role. Once the pod assumes the IAM role, it receives temporary credentials. These credentials are used to access AWS resources, such as S3 buckets or DynamoDB tables.
As long as the credentials remain valid, the AWS SDK or libraries within the pod cache and reuse them for subsequent API calls. This caching avoids frequent interaction with STS, improving efficiency.
When the credentials are about to expire, the AWS SDK automatically requests new temporary credentials by using the OIDC token (assuming the trust relationship and service account annotation are correctly configured).
Lambda / EC2
Lambda functions / EC2 assume IAM roles by attaching them directly. The service manages and uses these roles seamlessly.
Therefore , they can assume the role directly
Last updated
Was this helpful?