The AWS provider turns Secrets Manager and Parameter Store into mounted files

What the provider actually does inside the cluster

The AWS provider for the Secrets Store CSI Driver allows you to fetch secrets from AWS Secrets Manager and AWS Systems Manager Parameter Store and mount them into Kubernetes pods.

The two backing services have different characters. Secrets Manager is described as allowing you to easily rotate, manage and retrieve database credentials, API keys, certificates and other secrets throughout their lifecycle. Parameter Store provides hierarchical storage for configuration data. The provider talks to both, and the difference matters when you decide what goes where: a rotated database password belongs in Secrets Manager, a configuration value that an operator is expected to edit belongs in Parameter Store.

Architecturally, the provider is a plugin for the Secrets Store CSI Driver, which is a separate project under kubernetes-sigs. The driver is what implements the CSI interface and does the mounting; the provider is what knows how to authenticate to AWS and how to call the two services. The go.mod in this repository makes the split visible, with sigs.k8s.io/secrets-store-csi-driver at v1.6.0 as a dependency, along with the AWS SDK v2 packages for secretsmanager, ssm and sts, the Kubernetes api, apimachinery and client-go packages, and gRPC.

The provider also has a credential_provider directory alongside provider, server, utils, deployment, charts and examples, and the Dockerfile builds a static binary with CGO disabled into a scratch image, copying the certificate authorities from Amazon Linux 2 so that TLS calls to the AWS APIs work.

The primary language is Go, the licence is Apache-2.0, the last push was on 2026-10-22, and the recent releases are 3.1.4, 3.1.3 and 3.1.2.

Installing the driver and the provider, and the Fargate limitation

The requirements section sets out the constraints before any command, and one of them is disqualifying for a lot of people.

You need Amazon Elastic Kubernetes Service 1.17 or later running an EC2 node group, and Fargate node groups are not supported. The reason is given in a footnote: the CSI Secret Store driver runs as a DaemonSet, and DaemonSet is not supported on Fargate. If using the EKS Pod Identity feature, EKS 1.24 or later is required.

The driver itself is installed with Helm, adding the chart repository and installing the chart into kube-system:

    helm repo add secrets-store-csi-driver https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts
    helm install -n kube-system csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver

There are two notes here that save time. Older versions of the driver may require the --set grpcSupportedProviders="aws" flag on the install step. And this step can be skipped if you install from Helm for the ASCP, because the Helm chart for the ASCP automatically installs a compatible version of the Secrets Store CSI driver as a Helm dependency, which can be disabled by setting secrets-store-csi-driver.install=false.

The provider itself has two installation options. With Helm:

helm repo add aws-secrets-manager https://aws.github.io/secrets-store-csi-driver-provider-aws
helm install -n kube-system secrets-provider-aws aws-secrets-manager/secrets-store-csi-driver-provider-aws

Or with kubectl, applying the installer manifest directly:

kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/deployment/aws-provider-installer.yaml

Authentication is the other requirement, and it is per pod rather than per cluster: IAM Roles for Service Accounts, or EKS Pod Identity, as described in the usage section.

The tokenRequests detail that breaks standalone driver installs

There is one configuration step that is easy to miss and produces a confusing failure, and the README calls it out separately.

If you install the secrets-store-csi-driver separately rather than through the ASCP Helm chart, you must configure tokenRequests in the CSI driver for the AWS provider to authenticate with AWS services. With Helm that means an upgrade with two audiences set:

helm upgrade csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver \
  --set tokenRequests[0].audience="sts.amazonaws.com" \
  --set tokenRequests[1].audience="pods.eks.amazonaws.com"

Or, using kubectl, you add the equivalent to your CSIDriver manifest:

apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: secrets-store.csi.k8s.io
spec:
  tokenRequests:
    - audience: "sts.amazonaws.com"
    - audience: "pods.eks.amazonaws.com"

The two audiences are the mechanism by which the driver obtains credentials: one for the AWS Security Token Service, and one for the EKS Pod Identity agent. This is the part of the setup that people tend to leave out, because the install command succeeds either way, and the failure only shows up when a pod tries to mount its secret.

The rest of the requirements are the ordinary Kubernetes requirement of a service account with an IAM role attached, using IRSA or EKS Pod Identity as described in the usage section.

Walking through the example: a secret, a policy and a pod

The usage section is a complete worked example, and following it tells you what the moving parts are.

First you set the region and cluster name, because every command below needs them:

REGION=<REGION>
CLUSTERNAME=<CLUSTERNAME>

Then you create a test secret in Secrets Manager:

aws --region "$REGION" secretsmanager  create-secret --name MySecret --secret-string '{"username":"memeuser", "password":"hunter2"}'

Then you create an access policy scoped down to just the secrets the pod should have, and keep the policy ARN in a shell variable:

POLICY_ARN=$(aws --region "$REGION" --query Policy.Arn --output text iam create-policy --policy-name nginx-deployment-policy --policy-document '{
    "Version": "2012-10-17",
    "Statement": [ {
        "Effect": "Allow",
        "Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
        "Resource": ["arn:*:secretsmanager:*:*:secret:MySecret-??????"]
    } ]
}')

The README notes that when using SSM parameters the permission ssm:GetParameters is needed in the policy, and that the wild card matches in this example could be locked down further using the full ARN from the output of create-secret.

The IAM policy is the security boundary of the whole system, and the example shows it scoped to one secret by name. The role of the provider is to authenticate as the pod, and the role of the policy is to decide what that pod can read once it has.

IRSA, EKS Pod Identity and the SecretProviderClass

With a secret and a policy in place, the remaining work is identity and configuration.

For IRSA, the first step is creating the IAM OIDC provider for the cluster, which is a one-time operation:

eksctl utils associate-iam-oidc-provider --region="$REGION" --cluster="$CLUSTERNAME" --approve # Only run this once

Then you create the service account the pod will use and attach the policy to it. The example uses the name nginx-irsa-deployment-sa:

eksctl create iamserviceaccount --name nginx-irsa-deployment-sa --region="$REGION" --cluster "$CLUSTERNAME" --attach-policy-arn "$POLICY_ARN" --approve --override-existing-serviceaccounts

There is a network condition to note here: for a private cluster, ensure that the VPC the cluster is in has an AWS STS endpoint, so that the token exchange has somewhere to happen.

The SecretProviderClass is the object that tells the AWS provider which secrets to mount, and the example in the examples directory mounts MySecret:

kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/examples/ExampleSecretProviderClass-IRSA.yaml

Then the pod itself, with a sample nginx deployment that mounts the secrets under /mnt/secrets-store:

kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/examples/ExampleDeployment-IRSA.yaml

And the verification is a read of the mounted file from inside the pod:

kubectl exec -it $(kubectl get pods | awk '/nginx-irsa-deployment/{print $1}' | head -1) -- cat /mnt/secrets-store/MySecret; echo

The examples directory carries the parallel set of files for the other identity path, with ExampleDeployment-PodIdentity.yaml and ExampleSecretProviderClass-PodIdentity.yaml alongside the IRSA ones, and the README notes that the EKS Pod Identity option is only supported for EKS in the Cloud, not for other deployments.

Where this provider is the wrong choice

Three limits, and they are structural rather than defects.

The first is Fargate, and it is not negotiable within this architecture. The driver runs as a DaemonSet, and Fargate does not support DaemonSets, so the provider cannot run there at all. A team on Fargate who wants secrets as files has to use a different mechanism entirely.

The second is that the whole design is AWS-shaped in a way that has a cost. The pod needs an AWS identity, which means IRSA or EKS Pod Identity, which means an OIDC provider, a service account, a trust policy and a token request flow through the driver. Compare that with the simpler alternative of a secrets operator or an external secret sync into the cluster, where the pod does not need cloud credentials at all and the secret arrives through a different channel. The AWS-native path gives you per-pod IAM scoping and no second copy of the secret in etcd, which is a real advantage, and it also means a policy that can accidentally allow more than you intended.

The third is that this is a file mount, and file mounts have a lifecycle. The secret appears as a file in the pod's filesystem, and the file's permissions and ownership are part of the contract with the application. An application that expects credentials in environment variables needs different code, and a pod that gets its secret through this mechanism is a pod whose volume contents change when the secret rotates, which some applications handle badly.

The alternative approach, if you want files without the AWS identity machinery, is to sync the secret into a Kubernetes Secret with an external operator and mount that. The difference in approach is where the cloud credential lives: in this provider the pod's identity is the AWS identity and the IAM policy is the access control, while in the sync approach the pod authenticates to Kubernetes as usual and the cloud credential stays entirely outside the cluster, at the cost of the secret existing in etcd and of rotation no longer being instantaneous.

Editorial conclusion

Adopt this provider if you run workloads on EKS and want AWS secrets delivered as files to pods without baking credentials into images, because the driver handles rotation on the mount and the provider keeps the AWS-specific part separate from the CSI interface. Do not adopt it if your cluster is Fargate based, since the driver runs as a DaemonSet and Fargate does not support DaemonSets, and do not adopt it if you want secrets in environment variables or in a ConfigMap, because this mechanism delivers files. Verify first that your cluster meets the EKS 1.17 or later requirement, that you have a working IRSA OIDC provider or EKS Pod Identity for the cluster, that the secret names in your SecretProviderClass match what the IAM policy allows, and that the tokenRequests audiences are configured on the driver if you installed the driver separately from the chart.

Frequently asked questions

Official sources

1. aws/secrets-store-csi-driver-provider-aws on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases