AWS Security Blog
Announcing ASCP integration with Pod Identity: Enhanced security for secrets management in Amazon EKS
In 2021, Amazon Web Services (AWS) introduced the AWS Secrets and Configuration Provider (ASCP) for the Kubernetes Secrets Store Container Storage Interface (CSI) Driver, offering a reliable way to manage secrets in Amazon Elastic Kubernetes Service (Amazon EKS). Today, we’re excited to announce the integration of ASCP with Pod Identity, the new standard for AWS Identity and Access Management (IAM) integration with Amazon EKS. This integration provides enhanced security, simplified configuration, and improved Day-2 operation for applications running on EKS that need access to secrets stored in AWS Secrets Manager and AWS Systems Manager Parameter Store. In this post, we’ll cover use-case scenarios for single and cross-account secrets using Pod Identity integration with ASCP.
Amazon EKS introduced Pod Identity in 2023 as a feature that streamlines the process of configuring IAM permissions for Kubernetes applications. Pod Identity simplifies the identity management of applications running on top of Amazon EKS by allowing you to set up permissions directly through EKS interfaces, reducing the number of steps required and alleviating the need to switch between the EKS and IAM services. Pod Identity enables the use of a single IAM role across multiple clusters without updating trust policies, and it supports role session tags for more granular access control. This approach not only simplifies policy management by allowing the reuse of permission policies across roles, but also enhances security by enabling access to AWS resources based on matching tags.
Background
When your applications that are running on top of Amazon EKS require sensitive information like credentials to access a database, or a key to authenticate through an API, we call this kind of information secrets. You can secure, store, and manage secrets in AWS Secrets Manager. ASCP allows Kubernetes applications to securely retrieve the secrets stored in Secrets Manager and Systems Manager Parameter Store. Previously, ASCP relied on IAM roles for service accounts (IRSA) for authentication. Although IRSA provided improvements over previous methods, Pod Identity offers even greater security and simplicity.
Pod Identity provides a more secure and efficient way to integrate IAM roles with applications running on EKS, granting more granular AWS permissions to individual Pods, so that you don’t need instance-level credentials or IRSA.
This integration provides the following key benefits over using IRSA:
- Enhanced security: Pod Identity provides a more granular and secure way to manage permissions at the Pod level, alleviating the need to expose the IAM role annotation on Kubernetes ServiceAccount objects.
- Simplified configuration:Pod Identity streamlines and simplifies the setup process, reducing the potential for misconfiguration, especially in high-scale environments.
- Improved operation: Pod Identity reduces the operational overhead compared to previous methods, centralizing the management with the AWS API.
- Native EKS integration: Pod Identity is the new standard for IAM integration for applications running on EKS and provides a more cohesive experience.
Solution overview
With this integration, ASCP uses Pod Identity to authenticate and authorize access to AWS services. When a Pod requires access to a secret, the workflow is as shown in Figure 1.

Figure 1: The workflow performed by the Pod Identity and ASCP integration to provide access to a secret stored on AWS Secrets Manager for a Pod running on Amazon EKS
The workflow is as follows:
- A user creates an IAM role and a Pod Identity association between the IAM role and the Kubernetes ServiceAccount assigned to the Pod.
- EKS API validates the Pod Identity association, allowing ASCP to use this role to authenticate with AWS services.
- If authorized, the Pod Identity agent allows ASCP to assume the IAM role assigned to the Pod through the use of a ServiceAccount token.
- The Pod retrieves the requested secrets values and makes them available to the Pod through the use of a mounted volume.
Prerequisites
You need to have the following prerequisites in place in order to implement this solution:
- An Amazon EKS cluster (version 1.24 or later)
- Pod Identity enabled on your cluster
- Access to two AWS accounts (for cross-account access)
- AWS CLI installed
- kubectl installed
- Helm installed
Implement the solution
This guide presents two scenarios: single-account setup and cross-account setup. Complete the single-account steps in Account A before proceeding to the cross-account configuration, which involves Account B. The cross-account setup builds on the single-account foundation to demonstrate secure secrets management across AWS accounts.
Amazon EKS cluster setup
Before you start, you’ll need to set up an Amazon EKS cluster with the required add-ons in a single account (Account A).
- (Optional) Use the following commands to set environment variables and create an Amazon EKS cluster:
Here are the environment variables for this demonstration:
Create the EKS cluster:
- Update your
kubeconfig
file to enable Pod Identity on your EKS cluster (if it’s not already enabled): - Install the Secrets Store CSI driver:
- Verify the Secrets Store CSI Driver installation:
You should see this expected output:
- Install the ASCP plugin:
Consuming secrets in a single account
Now that you’ve set up your Amazon EKS cluster, in this use case, you’ll create an AWS Secrets Manager secret in the same account where the cluster and the applications reside (Account A).
- Create a secret in AWS Secrets Manager with tags
kubernetes-namespace
andeks-cluster-name
within the same AWS account as the EKS cluster:You should see this expected output:
Note the Amazon Resource Name (ARN) of the new secret. You will use it in the next step.
- Create an IAM role and trust policy with the required permissions to retrieve the newly created secret within the same AWS account:
In the preceding example IAM role permission policy, the use of conditions with
kubernetes-namespace
andeks-cluster-name
tags helps enforce fine-grained access control by specifying that secrets can only be accessed by Pods from specific namespace and clusters. This allowssecretsmanager
actions only if the secret is tagged with the matchingkubernetes-namespace
andeks-cluster-name
values.Notice that the preceding example IAM role trust policy allows the Amazon EKS Pod Identity service (
pods.eks.amazonaws.com
) to assume the role and tag the session. These actions are necessary for Pod Identity to function correctly, enabling Pods to securely access AWS resources.Finally, apply the role and trust policy:
Note the ARN of the new role. You will use it in the next step.
- Create a Kubernetes ServiceAccount and add the Pod Identity association between the ServiceAccount and the IAM role:
- Create a
SecretProviderClass
to use the newly created secret in your Amazon EKS cluster. - Create a new deployment to consume your newly created secret using Pod Identity as a mounted volume.
- Validate that the deployment was created successfully and confirm the secret was mounted correctly.
You should see this expected output:
Working with cross-account secrets through resource policies
For this second use case, you’ll also use the Amazon EKS cluster on Account A, and create a new Secrets Manager secret in a different account (Account B).
In order to access a secret in a different account, you can’t use the default AWS Key Management Service (AWS KMS) key, but will use aws/secretsmanager
to encrypt this secret. So you need to first create a new AWS KMS key that allows cross-account access.
On Account B
- Create a customer managed key on AWS KMS with cross-account permissions:
Then create the KMS key:
You should see this expected output:
Take note of the KeyID and the ARN of the key. You can use it to create an alias for the newly created key:
- Create a new secret in Secrets Manager, using the new KMS key to encrypt it:
You should see this expected output:
Note the ARN of the new secret. You will use it in the next step.
- Add a resource policy that allows the IAM role on Account A to access the newly created secret:
Now let’s go back to Account A.
On Account A
- Create a new IAM role and trust policy with the required permissions to retrieve the newly created secret within Account B:
In the preceding example IAM role permission policy, note that the resource ARN is pointing to the secret created on Account B.
The IAM role trust policy needs to have
pods.eks.amazonaws.com
as a trusted entity to perform thests:AssumeRole
andsts:TagSession
actions.Next, create the role and apply the policy:
Note the ARN of the new role. You will use it in the next step.
- Create the second Kubernetes ServiceAccount and add the cross-account Pod Identity association:
- Create a
SecretProviderClass
to use the cross-account secret created in Account B in your Amazon EKS cluster: - Create a new deployment to consume your newly created secret using Pod Identity as a mounted volume:
- Validate that the deployment was created successfully and confirm the mounted secret:
Note that the volume name is the secret ARN, because it’s a cross-account secret.
You should see this expected output:
Conclusion
The integration of ASCP with Pod Identity marks a significant step forward in secrets management for Amazon EKS. It offers enhanced security, simplified configuration, and improved operations. We encourage all EKS users to explore this new integration and take advantage of its benefits.
The integration of ASCP with Pod Identity offers these benefits over IRSA:
- Simplified setup: With Pod Identity, you don’t need to create and manage service accounts for each application.
- Enhanced security: Pod Identity provides more granular control over permissions at the Pod level.
- Improved scalability: Pod Identity is easier to implement in large-scale environments.
- Consistent AWS experience: Pod Identity aligns more closely with AWS best practices for IAM management.
For more information, see our documentation for: AWS Secrets Manager, AWS Secrets CSI Store Provider (ASCP), and Amazon EKS Pod Identity.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.