{ "id": "6c598123-feba-4721-a551-c7c310c6c384", "created_at": "2026-04-06T01:32:01.227156Z", "updated_at": "2026-04-10T03:20:25.059412Z", "deleted_at": null, "sha1_hash": "b438d4f96dbbf586cb2fc7d5f2db0cb43ef57f48", "title": "IAM roles for service accounts", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 54109, "plain_text": "IAM roles for service accounts\r\nArchived: 2026-04-06 00:41:13 UTC\r\nHelp improve this page\r\nTo contribute to this user guide, choose the Edit this page on GitHub link that is located in the right pane of\r\nevery page.\r\nHelp improve this page\r\nTo contribute to this user guide, choose the Edit this page on GitHub link that is located in the right pane of\r\nevery page.\r\nTip\r\nRegister for upcoming Amazon EKS workshops.\r\nApplications in a Pod’s containers can use an AWS SDK or the AWS CLI to make API requests to AWS services\r\nusing AWS Identity and Access Management (IAM) permissions. Applications must sign their AWS API requests\r\nwith AWS credentials. IAM roles for service accounts (IRSA) provide the ability to manage credentials for your\r\napplications, similar to the way that Amazon EC2 instance profiles provide credentials to Amazon EC2 instances.\r\nInstead of creating and distributing your AWS credentials to the containers or using the Amazon EC2 instance’s\r\nrole, you associate an IAM role with a Kubernetes service account and configure your Pods to use the service\r\naccount. You can’t use IAM roles for service accounts with local clusters for Amazon EKS on AWS Outposts.\r\nIAM roles for service accounts provide the following benefits:\r\nLeast privilege – You can scope IAM permissions to a service account, and only Pods that use that service\r\naccount have access to those permissions. This feature also eliminates the need for third-party solutions\r\nsuch as kiam or kube2iam .\r\nCredential isolation – When access to the Amazon EC2 Instance Metadata Service (IMDS) is restricted, a\r\nPod’s containers can only retrieve credentials for the IAM role that’s associated with the service account\r\nthat the container uses. A container never has access to credentials that are used by other containers in other\r\nPods. If IMDS is not restricted, the Pod’s containers also have access to the Amazon EKS node IAM role\r\nand the containers may be able to gain access to credentials of IAM roles of other Pods on the same node.\r\nFor more information, see Restrict access to the instance profile assigned to the worker node.\r\nNote\r\nPods configured with hostNetwork: true will always have IMDS access, but the AWS SDKs and CLI will use\r\nIRSA credentials when enabled.\r\nhttps://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html\r\nPage 1 of 3\n\nAuditability – Access and event logging is available through AWS CloudTrail to help ensure retrospective\r\nauditing.\r\nImportant\r\nContainers are not a security boundary, and the use of IAM roles for service accounts does not change this. Pods\r\nassigned to the same node will share a kernel and potentially other resources depending on your Pod\r\nconfiguration. While Pods running on separate nodes will be isolated at the compute layer, there are node\r\napplications that have additional permissions in the Kubernetes API beyond the scope of an individual instance.\r\nSome examples are kubelet , kube-proxy , CSI storage drivers, or your own Kubernetes applications.\r\nEnable IAM roles for service accounts by completing the following procedures:\r\n1. Create an IAM OIDC provider for your cluster – You only complete this procedure once for each cluster.\r\nNote\r\nIf you enabled the EKS VPC endpoint, the EKS OIDC service endpoint couldn’t be accessed from inside\r\nthat VPC. Consequently, your operations such as creating an OIDC provider with eksctl in the VPC will\r\nnot work and will result in a timeout when attempting to request\r\nhttps://oidc.eks. region .amazonaws.com . An example error message follows:\r\nserver cant find oidc.eks.region.amazonaws.com: NXDOMAIN\r\nTo complete this step, you can run the command outside the VPC, for example in AWS CloudShell or on a\r\ncomputer connected to the internet. Alternatively, you can create a split-horizon conditional resolver in the\r\nVPC, such as Route 53 Resolver to use a different resolver for the OIDC Issuer URL and not use the VPC\r\nDNS for it. For an example of conditional forwarding in CoreDNS, see the Amazon EKS feature request\r\non GitHub.\r\n2. Assign IAM roles to Kubernetes service accounts – Complete this procedure for each unique set of\r\npermissions that you want an application to have.\r\n3. Configure Pods to use a Kubernetes service account – Complete this procedure for each Pod that needs\r\naccess to AWS services.\r\n4. Use IRSA with the AWS SDK – Confirm that the workload uses an AWS SDK of a supported version and\r\nthat the workload uses the default credential chain.\r\nIAM, Kubernetes, and OpenID Connect (OIDC) background information\r\nIn 2014, AWS Identity and Access Management added support for federated identities using OpenID Connect\r\n(OIDC). This feature allows you to authenticate AWS API calls with supported identity providers and receive a\r\nvalid OIDC JSON web token (JWT). You can pass this token to the AWS STS AssumeRoleWithWebIdentity API\r\nhttps://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html\r\nPage 2 of 3\n\noperation and receive IAM temporary role credentials. You can use these credentials to interact with any AWS\r\nservice, including Amazon S3 and DynamoDB.\r\nEach JWT token is signed by a signing key pair. The keys are served on the OIDC provider managed by Amazon\r\nEKS and the private key rotates every 7 days. Amazon EKS keeps the public keys until they expire. If you connect\r\nexternal OIDC clients, be aware that you need to refresh the signing keys before the public key expires. Learn\r\nhow to Fetch signing keys to validate OIDC tokens.\r\nKubernetes has long used service accounts as its own internal identity system. Pods can authenticate with the\r\nKubernetes API server using an auto-mounted token (which was a non-OIDC JWT) that only the Kubernetes API\r\nserver could validate. These legacy service account tokens don’t expire, and rotating the signing key is a difficult\r\nprocess. In Kubernetes version 1.12 , support was added for a new ProjectedServiceAccountToken feature.\r\nThis feature is an OIDC JSON web token that also contains the service account identity and supports a\r\nconfigurable audience.\r\nAmazon EKS hosts a public OIDC discovery endpoint for each cluster that contains the signing keys for the\r\nProjectedServiceAccountToken JSON web tokens so external systems, such as IAM, can validate and accept the\r\nOIDC tokens that are issued by Kubernetes.\r\nSource: https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html\r\nhttps://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html\r\nPage 3 of 3", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html" ], "report_names": [ "iam-roles-for-service-accounts.html" ], "threat_actors": [], "ts_created_at": 1775439121, "ts_updated_at": 1775791225, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/b438d4f96dbbf586cb2fc7d5f2db0cb43ef57f48.pdf", "text": "https://archive.orkl.eu/b438d4f96dbbf586cb2fc7d5f2db0cb43ef57f48.txt", "img": "https://archive.orkl.eu/b438d4f96dbbf586cb2fc7d5f2db0cb43ef57f48.jpg" } }