

# Use AWS Secrets Manager secrets in Amazon Elastic Kubernetes Service
<a name="integrate_eks"></a>

To show secrets from AWS Secrets Manager (ASCP) as files mounted in Amazon EKS Pods, you can use the AWS Secrets and Configuration Provider for the Kubernetes Secrets Store CSI Driver. The ASCP works with Amazon Elastic Kubernetes Service 1.17\$1 running an Amazon EC2 node group. AWS Fargate node groups are not supported. With the ASCP, you can store and manage your secrets in Secrets Manager and then retrieve them through your workloads running on Amazon EKS. If your secret contains multiple key-value pairs in JSON format, you can choose which ones to mount in Amazon EKS. The ASCP uses JMESPath syntax to query the key-value pairs in your secret. The ASCP also works with Parameter Store parameters. The ASCP offers two methods of authentication with Amazon EKS The first approach uses IAM Roles for Service Accounts (IRSA). The second approach uses Pod Identities. Each approach has its benefits and use cases.

## ASCP with IAM Roles for Service Accounts (IRSA)
<a name="csi_driver_overview"></a>

The ASCP with IAM Roles for Service Accounts (IRSA) allows you to mount secrets from AWS Secrets Manager as files in your Amazon EKS Pods. This approach is suitable when:
+ You need to mount secrets as files in your Pods.
+ You're using Amazon EKS version 1.17 or later with Amazon EC2 node groups.
+ You want to retrieve specific key-value pairs from JSON-formatted secrets.

For more information, see [Use AWS Secrets and Configuration Provider CSI with IAM Roles for Service Accounts (IRSA)](integrating_ascp_irsa.md).

## ASCP with Pod Identity
<a name="pod_identity_overview"></a>

The ASCP with Pod Identity method enhances security and simplifies configuration for accessing secrets in Amazon EKS. This approach is beneficial when:
+ You need more granular permission management at the Pod level.
+ You're using Amazon EKS version 1.24 or later.
+ You want improved performance and scalability.

For more information, see [Use AWS Secrets and Configuration Provider CSI with Pod Identity for Amazon EKS](ascp-pod-identity-integration.md).

## Choosing the right approach
<a name="comparison"></a>

Consider the following factors when deciding between ASCP with IRSA and ASCP with Pod Identity:
+ Amazon EKSversion: Pod Identity requires Amazon EKS 1.24\$1, while CSI driver works with Amazon EKS 1.17\$1.
+ Security requirements: Pod Identity offers more granular control at the Pod level.
+ Performance: Pod Identity generally performs better in high-scale environments.
+ Complexity: Pod Identity simplifies setup by eliminating the need for separate service accounts.

Choose the method that best aligns with your specific requirements and Amazon EKS environment.

# Install ASCP for Amazon EKS
<a name="ascp-eks-installation"></a>

This section explains how to install the AWS Secrets and Configuration Provider for Amazon EKS. With ASCP, you can mount secrets from Secrets Manager and parameters from AWS Systems Manager as files in Amazon EKS Pods.

## Prerequisites
<a name="prerequisites"></a>
+ An Amazon EKS cluster
  + Version 1.24 or later for Pod Identity
  + Version 1.17 or later for IRSA
+ The AWS CLI installed and configured
+ kubectl installed and configured for your Amazon EKS cluster
+ Helm (version 3.0 or later)

## Install and configure the ASCP
<a name="integrating_csi_driver_install"></a>

The ASCP is available on GitHub in the [secrets-store-csi-provider-aws](https://github.com/aws/secrets-store-csi-driver-provider-aws) repository. The repo also contains example YAML files for creating and mounting a secret. 

During installation, you can configure the ASCP to use a FIPS endpoint. For a list of endpoints, see [AWS Secrets Manager endpoints](asm_access.md#endpoints).

**To install the ASCP as an EKS add-on**

1. Install `eksctl` ([installation instructions](https://docs.aws.amazon.com/eks/latest/eksctl/installation.html))

1. Run the following command to install the add-on with the [default configuration](https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/main/charts/secrets-store-csi-driver-provider-aws/values.yaml):

   ```
   eksctl create addon --cluster <your_cluster> --name aws-secrets-store-csi-driver-provider
   ```

   If you'd like to configure the add-on, run the following installation command instead:

   ```
   aws eks create-addon --cluster-name <your_cluster> --addon-name aws-secrets-store-csi-driver-provider --configuration-values 'file://path/to/config.yaml'
   ```

   The configuration file can be a YAML or JSON file. To see the configuration schema for the add-on:

   1. Run the following command and note the latest version of the add-on:

      ```
      aws eks describe-addon-versions --addon-name aws-secrets-store-csi-driver-provider
      ```

   1. Run the following command to see the add-on's configuration schema, replacing `<version>` with the version from the previous step:

      ```
      aws eks describe-addon-configuration --addon-name aws-secrets-store-csi-driver-provider --addon-version <version>
      ```

**To install the ASCP by using Helm**

1. To make sure the repo is pointing to the latest charts, use `helm repo update.`

1. Install the chart. The following is an example of the `helm install` command:

   ```
   helm install -n kube-system secrets-provider-aws aws-secrets-manager/secrets-store-csi-driver-provider-aws
   ```

   1. To use a FIPS endpoint, add the following flag: `--set useFipsEndpoint=true`

   1. To configure throttling, add the following flag: `--set-json 'k8sThrottlingParams={"qps": "number of queries per second", "burst": "number of queries per second"}'`

   1. If the Secrets Store CSI Driver is already installed on your cluster, add the following flag: `--set secrets-store-csi-driver.install=false`. This will skip installing Secrets Store CSI Driver as a dependency.

**To install by using the YAML in the repo**
+ Use the following commands.

  ```
  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
  kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/deployment/aws-provider-installer.yaml
  ```

## Verify the installations
<a name="verify-ascp-installations"></a>

To verify the installations of your EKS cluster, Secrets Store CSI driver, and ASCP plugin, follow these steps:

1. Verify the EKS cluster:

   ```
   eksctl get cluster --name clusterName
   ```

   This command should return information about your cluster.

1. Verify the Secrets Store CSI driver installation:

   ```
   kubectl get pods -n kube-system -l app=secrets-store-csi-driver
   ```

   You should see Pods running with names like `csi-secrets-store-secrets-store-csi-driver-xxx`.

1. Verify the ASCP plugin installation:

------
#### [ YAML installation ]

   ```
   $ kubectl get pods -n kube-system -l app=csi-secrets-store-provider-aws
   ```

   Example output:

   ```
   NAME                                     READY   STATUS    RESTARTS   AGE
   csi-secrets-store-provider-aws-12345      1/1     Running   0          2m
   ```

------
#### [ Helm installation ]

   ```
   $  kubectl get pods -n kube-system -l app=secrets-store-csi-driver-provider-aws
   ```

   Example output:

   ```
   NAME                                              READY   STATUS    RESTARTS   AGE
   secrets-provider-aws-secrets-store-csi-driver-provider-67890       1/1     Running   0          2m
   ```

------

   You should see Pods in the `Running` state.

After running these commands, if everything is set up correctly, you should see all components running without any errors. If you encounter any issues, you may need to troubleshoot by checking the logs of the specific Pods that are having problems.

## Troubleshooting
<a name="troubleshooting"></a>

1. To check the logs of the ASCP provider, run:

   ```
   kubectl logs -n kube-system -l app=csi-secrets-store-provider-aws
   ```

1. Check the status of all pods in the `kube-system` namespace:

   ```
   kubectl -n kube-system get pods
   ```

   ```
   kubectl -n kube-system logs pod/PODID
   ```

   All Pods related to the CSI driver and ASCP should be in the 'Running' state.

1. Check the CSI driver version:

   ```
   kubectl get csidriver secrets-store.csi.k8s.io -o yaml
   ```

   This command should return information about the installed CSI driver.

## Additional resources
<a name="additional-resources"></a>

For more information about using ASCP with Amazon EKS, see the following resources:
+ [Using Pod Identity with Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)
+ [AWS Secrets Store CSI Driver on GitHub](https://github.com/aws/secrets-store-csi-driver-provider-aws)

# Use AWS Secrets and Configuration Provider CSI with Pod Identity for Amazon EKS
<a name="ascp-pod-identity-integration"></a>

The AWS Secrets and Configuration Provider integration with the Pod Identity Agent for Amazon Elastic Kubernetes Service provides enhanced security, simplified configuration, and improved performance for applications running on Amazon EKS. Pod Identity simplifies IAM authentication for Amazon EKS when retrieving secrets from Secrets Manager or parameters from AWS Systems Manager Parameter Store.

Amazon EKS Pod Identity streamlines the process of configuring IAM permissions for Kubernetes applications by allowing permissions to be set up directly through Amazon EKS interfaces, reducing the number of steps and eliminating the need to switch between Amazon EKS and IAM services. Pod Identity enables the use of a single IAM role across multiple clusters without updating trust policies and supports [role session tags](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#pod-id-abac-tags) for more granular access control. This approach not only simplifies policy management by allowing reuse of permission policies across roles but also enhances security by enabling access to AWS resources based on matching tags.

## How it works
<a name="how-it-works"></a>

1. Pod Identity assigns an IAM role to the Pod.

1. ASCP uses this role to authenticate with AWS services.

1. If authorized, ASCP retrieves the requested secrets and makes them available to the Pod.

For more information, see [Understand how Amazon EKS Pod Identity works](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html) in the *Amazon EKS User Guide*.

## Prerequisites
<a name="prerequisites"></a>

**Important**  
Pod Identity is supported only for Amazon EKS in the cloud. It is not supported for [Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/), [Red Hat OpenShift Service on AWS](https://aws.amazon.com/rosa/), or self-managed Kubernetes clusters on Amazon EC2 instances.
+ Amazon EKS cluster (version 1.24 or later)
+ Access to AWS CLI and Amazon EKS cluster via `kubectl`
+ Access to two AWS accounts (for cross-account access)

## Install the Amazon EKS Pod Identity Agent
<a name="install-pod-identity-agent"></a>

To use Pod Identity with your cluster, you must install the Amazon EKS Pod Identity Agent add-on.

**To install the Pod Identity Agent**
+ Install the Pod Identity Agent add-on on your cluster:

  ```
  eksctl create addon \
    --name eks-pod-identity-agent \
    --cluster clusterName \
    --region region
  ```

## Set up ASCP with Pod Identity
<a name="pod-identity-setup"></a>

1. Create a permissions policy that grants `secretsmanager:GetSecretValue` and `secretsmanager:DescribeSecret` permission to the secrets that the Pod needs to access. For an example policy, see [Example: Permission to read and describe individual secrets](auth-and-access_iam-policies.md#auth-and-access_examples-read-and-describe).

1. Create an IAM role that can be assumed by the Amazon EKS service principal for Pod Identity:

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
         {
           "Effect": "Allow",
           "Principal": {
             "Service": "pods.eks.amazonaws.com"
           },
           "Action": [
             "sts:AssumeRole",
             "sts:TagSession"
           ]
         }
       ]
     }
   ```

------

   Attach the IAM policy to the role:

   ```
   aws iam attach-role-policy \
     --role-name MY_ROLE \
     --policy-arn POLICY_ARN
   ```

1. Create a Pod Identity association. For an example, see [Create a Pod Identity association ](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html#pod-id-association-create) in the *Amazon EKS User Guide*

1. Create the `SecretProviderClass` that specifies which secrets to mount in the Pod:

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

   The key difference in `SecretProviderClass` between IRSA and Pod Identity is the optional parameter `usePodIdentity`. It is an optional field that determines the authentication approach. When not specified, it defaults to using IAM Roles for Service Accounts (IRSA).
   + To use EKS Pod Identity, use any of these values: `"true", "True", "TRUE", "t", "T"`.
   + To explicitly use IRSA, set to any of these values: `"false", "False", "FALSE", "f", or "F"`.

1. Deploy the Pod 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-PodIdentity.yaml
   ```

1. If you use a private Amazon EKS cluster, make sure that the VPC that the cluster is in has an AWS STS endpoint. For information about creating an endpoint, see [Interface VPC endpoints](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_interface_vpc_endpoints.html) in the *AWS Identity and Access Management User Guide*.

### Verify the secret mount
<a name="verify-secret-mount"></a>

To verify that the secret is mounted properly, run the following command:

```
kubectl exec -it $(kubectl get pods | awk '/pod-identity-deployment/{print $1}' | head -1) -- cat /mnt/secrets-store/MySecret
```

**To set up Amazon EKS Pod Identity to access to secrets in Secrets Manager**

1. Create a permissions policy that grants `secretsmanager:GetSecretValue` and `secretsmanager:DescribeSecret` permission to the secrets that the Pod needs to access. For an example policy, see [Example: Permission to read and describe individual secrets](auth-and-access_iam-policies.md#auth-and-access_examples-read-and-describe).

1. Create a secret in Secrets Manager, if you do not already have one.

## Troubleshoot
<a name="integrating_aspc_pod_trouble"></a>

You can view most errors by describing the Pod deployment.

**To see error messages for your container**

1. Get a list of Pod names with the following command. If you aren't using the default namespace, use `-n NAMESPACE`.

   ```
   kubectl get pods
   ```

1. To describe the Pod, in the following command, for *PODID* use the Pod ID from the Pods you found in the previous step. If you aren't using the default namespace, use `-n NAMESPACE`.

   ```
   kubectl describe pod/PODID
   ```

**To see errors for the ASCP**
+ To find more information in the provider logs, in the following command, for *PODID* use the ID of the *csi-secrets-store-provider-aws* Pod.

  ```
  kubectl -n kube-system get pods
  kubectl -n kube-system logs pod/PODID
  ```

# Use AWS Secrets and Configuration Provider CSI with IAM Roles for Service Accounts (IRSA)
<a name="integrating_ascp_irsa"></a>

**Topics**
+ [

## Prerequisites
](#prerequisites)
+ [

## Set up access control
](#integrating_ascp_irsa_access)
+ [

## Identify which secrets to mount
](#integrating_ascp_irsa_mount)
+ [

## Troubleshoot
](#integrating_ascp_irsa_trouble)

## Prerequisites
<a name="prerequisites"></a>
+ Amazon EKS cluster (version 1.17 or later)
+ Access to AWS CLI and Amazon EKS cluster via `kubectl`

## Set up access control
<a name="integrating_ascp_irsa_access"></a>

The ASCP retrieves the Amazon EKS Pod Identity and exchanges it for an IAM role. You set permissions in an IAM policy for that IAM role. When the ASCP assumes the IAM role, it gets access to the secrets you authorized. Other containers can't access the secrets unless you also associate them with the IAM role. 

**To grant your Amazon EKS Pod access to secrets in Secrets Manager**

1. Create a permissions policy that grants `secretsmanager:GetSecretValue` and `secretsmanager:DescribeSecret` permission to the secrets that the Pod needs to access. For an example policy, see [Example: Permission to read and describe individual secrets](auth-and-access_iam-policies.md#auth-and-access_examples-read-and-describe).

1. Create an IAM OpenID Connect (OIDC) provider for the cluster if you don't already have one. For more information, see [Create an IAM OIDC provider for your cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html) in the *Amazon EKS User Guide*.

1. Create an [IAM role for service account](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) and attach the policy to it. For more information, see [Create an IAM role for a service account](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) in the *Amazon EKS User Guide*.

1. If you use a private Amazon EKS cluster, make sure that the VPC that the cluster is in has an AWS STS endpoint. For information about creating an endpoint, see [Interface VPC endpoints](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_interface_vpc_endpoints.html) in the *AWS Identity and Access Management User Guide*.

## Identify which secrets to mount
<a name="integrating_ascp_irsa_mount"></a>

To determine which secrets the ASCP mounts in Amazon EKS as files on the filesystem, you create a [SecretProviderClass](ascp-examples.md#ascp-examples-secretproviderclass) YAML file. The `SecretProviderClass` lists the secrets to mount and the file name to mount them as. The `SecretProviderClass` must be in the same namespace as the Amazon EKS Pod it references.

### Mount the secrets as files
<a name="mount-secrets"></a>

The following instructions show how to mount secrets as files using example YAML files [ExampleSecretProviderClass.yaml](https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/main/examples/ExampleSecretProviderClass-IRSA.yaml) and [ExampleDeployment.yaml](https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/main/examples/ExampleDeployment-IRSA.yaml).

**To mount secrets in Amazon EKS**

1. Apply the `SecretProviderClass` to the Pod:

   ```
   kubectl apply -f ExampleSecretProviderClass.yaml
   ```

1. Deploy your Pod:

   ```
   kubectl apply -f ExampleDeployment.yaml
   ```

1. The ASCP mounts the files.

## Troubleshoot
<a name="integrating_ascp_irsa_trouble"></a>

You can view most errors by describing the Pod deployment. 

**To see error messages for your container**

1. Get a list of Pod names with the following command. If you aren't using the default namespace, use `-n nameSpace`.

   ```
   kubectl get pods
   ```

1. To describe the Pod, in the following command, for *podId* use the Pod ID from the Pods you found in the previous step. If you aren't using the default namespace, use `-n nameSpace`.

   ```
   kubectl describe pod/podId
   ```

**To see errors for the ASCP**
+ To find more information in the provider logs, in the following command, for *podId* use the ID of the *csi-secrets-store-provider-aws* Pod.

  ```
  kubectl -n kube-system get pods
  kubectl -n kube-system logs Pod/podId
  ```
+ 

**Verify that the `SecretProviderClass` CRD is installed:**

  ```
  kubectl get crd secretproviderclasses.secrets-store.csi.x-k8s.io
  ```

  This command should return information about the `SecretProviderClass` custom resource definition.
+ 

**Verify that the SecretProviderClass object was created.**

  ```
  kubectl get secretproviderclass SecretProviderClassName -o yaml
  ```

# AWS Secrets and Configuration Provider code examples
<a name="ascp-examples"></a>

## ASCP authentication and access control examples
<a name="ascp-auth-access-examples"></a>

### Example: IAM policy allowing Amazon EKS Pod Identity service (pods.eks.amazonaws.com) to assume the role and tag the session:
<a name="w2aac19c17c18b5b3"></a>

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ]
    }
  ]
}
```

------

## SecretProviderClass
<a name="ascp-examples-secretproviderclass"></a>

You use YAML to describe which secrets to mount in Amazon EKS using the ASCP. For examples, see [SecretProviderClass usage](#ascp-scenarios-secretproviderclass).

### SecretProviderClass YAML structure
<a name="w2aac19c17c18c25b5"></a>

```
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
   name: name
spec:
  provider: aws
  parameters:
    region:
    failoverRegion:
    pathTranslation:
    usePodIdentity:
    preferredAddressType:
    objects:
```

The parameters field contains the details of the mount request:

**region**  
(Optional) The AWS Region of the secret. If you don't use this field, the ASCP looks up the Region from the annotation on the node. This lookup adds overhead to mount requests, so we recommend that you provide the Region for clusters that use large numbers of Pods.  
If you also specify `failoverRegion`, the ASCP tries to retrieve the secret from both Regions. If either Region returns a 4xx error, for example for an authentication issue, the ASCP does not mount either secret. If the secret is retrieved successfully from `region`, then the ASCP mounts that secret value. If the secret is not retrieved successfully from `region`, but it is retrieved successfully from `failoverRegion`, then the ASCP mounts that secret value.

**failoverRegion**  
(Optional) If you include this field, the ASCP tries to retrieve the secret from the Regions defined in `region` and this field. If either Region returns a 4xx error, for example for an authentication issue, the ASCP does not mount either secret. If the secret is retrieved successfully from `region`, then the ASCP mounts that secret value. If the secret is not retrieved successfully from `region`, but it is retrieved successfully from `failoverRegion`, then the ASCP mounts that secret value. For an example of how to use this field, see [Multi-Region secret failover](#multi-region-failover).

**pathTranslation**  
(Optional) A single substitution character to use if the file name in Amazon EKS will contain the path separator character, such as slash (/) on Linux. The ASCP can't create a mounted file that contains a path separator character. Instead, the ASCP replaces the path separator character with a different character. If you don't use this field, the replacement character is underscore (\$1), so for example, `My/Path/Secret` mounts as `My_Path_Secret`.   
To prevent character substitution, enter the string `False`.

**usePodIdentity**  
(Optional) Determines the authentication approach. When not specified, it defaults to IAM Roles for Service Accounts (IRSA) (IRSA).  
+ To use EKS Pod Identity, use any of these values: `"true"`", `"True"`, `"TRUE"`, `"t"`, or `"T"`.
+ To explicitly use IRSA, set to any of these values: `"false"`, `"False"`, `"FALSE"`, `"f"`, or `"F"`"=.

**preferredAddressType**  
(Optional) Specifies the preferred IP address type for Pod Identity Agent endpoint communication. The field is only applicable when using EKS Pod Identity feature and will be ignored when using IAM Roles for Service Accounts.Values are case-insensitive. Valid values are:  
+ `"ipv4"`, `"IPv4"`", or `"IPV4"` – Force the use of Pod Identity Agent IPv4 endpoint
+ `"ipv6"`, `"IPv6"`, or `"IPV6"` – Force the use of Pod Identity Agent IPv6 endpoint
+ not specified – Use auto endpoint selection, trying IPv4 endpoint first and falling back to IPv6 endpoint if IPv4 fails

**objects**  
A string containing a YAML declaration of the secrets to be mounted. We recommend using a YAML multi-line string or pipe (\$1) character.    
**objectName**  
Required. Specifies the name of the secret or parameter to be fetched. For Secrets Manager this is the [https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html#API_GetSecretValue_RequestParameters](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html#API_GetSecretValue_RequestParameters) parameter and can be either the friendly name or full ARN of the secret. For SSM Parameter Store, this is the [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html#API_GetParameter_RequestParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html#API_GetParameter_RequestParameters) of the parameter and can be either the name or full ARN of the parameter.  
**objectType**  
Required if you don't use a Secrets Manager ARN for `objectName`. Can be either `secretsmanager` or `ssmparameter`.   
**objectAlias**  
(Optional) The file name of the secret in the Amazon EKS Pod. If you don't specify this field, the `objectName` appears as the file name.  
**filePermission**  
(Optional) The 4 digit octal string which specifies the file permission to mount secret with. If you don't specify this field it will default to `"0644"`.   
**objectVersion**  
(Optional) The version ID of the secret. Not recommended because you must update the version ID every time you update the secret. By default the most recent version is used. If you include a `failoverRegion`, this field represents the primary `objectVersion`.  
**objectVersionLabel**  
(Optional) The alias for the version. The default is the most recent version AWSCURRENT. For more information, see [Secret versions](whats-in-a-secret.md#term_version). If you include a `failoverRegion`, this field represents the primary `objectVersionLabel`.  
**jmesPath**  
(Optional) A map of the keys in the secret to the files to be mounted in Amazon EKS. To use this field, your secret value must be in JSON format. If you use this field, you must include the subfields `path` and `objectAlias`.    
**path**  
A key from a key-value pair in the JSON of the secret value. If the field contains a hyphen, use single quotes to escape it, for example: `path: '"hyphenated-path"'`  
**objectAlias**  
The file name to be mounted in the Amazon EKS Pod. If the field contains a hyphen, use single quotes to escape it, for example: `objectAlias: '"hyphenated-alias"'`  
**filePermission**  
(Optional) The 4 digit octal string which specifies the file permission to mount secret with. If you don't specify this field it will default to the parent object's file permission.   
**failoverObject**  
(Optional) If you specify this field, the ASCP tries to retrieve both the secret specified in the primary `objectName` and the secret specified in the `failoverObject` `objectName` sub-field. If either returns a 4xx error, for example for an authentication issue, the ASCP does not mount either secret. If the secret is retrieved successfully from the primary `objectName`, then the ASCP mounts that secret value. If the secret is not retrieved successfully from the primary `objectName`, but it is retrieved successfully from the failover `objectName`, then the ASCP mounts that secret value. If you include this field, you must include the field `objectAlias`. For an example of how to use this field, see [Failover to a different secret](#failover-secret).  
You typically use this field when the failover secret isn't a replica. For an example of how to specify a replica, see [Multi-Region secret failover](#multi-region-failover).    
**objectName**  
The name or full ARN of the failover secret. If you use an ARN, the Region in the ARN must match the field `failoverRegion`.  
**objectVersion**  
(Optional) The version ID of the secret. Must match the primary `objectVersion`. Not recommended because you must update the version ID every time you update the secret. By default the most recent version is used.   
**objectVersionLabel**  
(Optional) The alias for the version. The default is the most recent version AWSCURRENT. For more information, see [Secret versions](whats-in-a-secret.md#term_version). 

### Create a basic SecretProviderClass configuration to mount secrets in your Amazon EKS Pods.
<a name="w2aac19c17c18c25c11"></a>

------
#### [ Pod Identity ]

SecretProviderClass to use a secret in the same Amazon EKS cluster:

```
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: aws-secrets-manager
spec:
  provider: aws
  parameters:
    objects: |
      - objectName: "mySecret"
        objectType: "secretsmanager"
    usePodIdentity: "true"
```

------
#### [ IRSA ]

```
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: deployment-aws-secrets
spec:
  provider: aws
  parameters:
    objects: |
        - objectName: "MySecret"
          objectType: "secretsmanager"
```

------

### SecretProviderClass usage
<a name="ascp-scenarios-secretproviderclass"></a>

Use these examples to create SecretProviderClass configurations for different scenarios.

#### Example: Mount secrets by name or ARN
<a name="mount-by-name-arn"></a>

This example shows how to mount three different types of secrets:
+ A secret specified by full ARN
+ A secret specified by name
+ A specific version of a secret

```
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: aws-secrets
spec:
  provider: aws
  parameters:
    objects: |
      - objectName: "arn:aws:secretsmanager:us-east-2:777788889999:secret:MySecret2-d4e5f6"
      - objectName: "MySecret3"
        objectType: "secretsmanager"
      - objectName: "MySecret4"
        objectType: "secretsmanager"
        objectVersionLabel: "AWSCURRENT"
```

#### Example: Mount key-value pairs from a secret
<a name="mount-key-value-pairs"></a>

This example shows how to mount specific key-value pairs from a JSON-formatted secret:

```
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: aws-secrets
spec:
  provider: aws
  parameters:
    objects: |
      - objectName: "arn:aws:secretsmanager:us-east-2:777788889999:secret:MySecret-a1b2c3"
        jmesPath: 
            - path: username
              objectAlias: dbusername
            - path: password
              objectAlias: dbpassword
```

#### Example: Mount secrets by file permission
<a name="mount-by-permission"></a>

This example shows how to mount a secret with a specific file permission

```
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: aws-secrets
spec:
  provider: aws
  parameters:
    objects: |
      - objectName: "mySecret"
        objectType: "secretsmanager"
        filePermission: "0600"
        jmesPath: 
            - path: username
              objectAlias: dbusername
              filePermission: "0400"
```

#### Example: Failover configuration examples
<a name="failover-examples"></a>

These examples show how to configure failover for secrets.

##### Multi-Region secret failover
<a name="multi-region-failover"></a>

This example shows how to configure automatic failover for a secret replicated across multiple Regions:

```
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: aws-secrets
spec:
  provider: aws
  parameters:
    region: us-east-1
    failoverRegion: us-east-2
    objects: |
      - objectName: "MySecret"
```

##### Failover to a different secret
<a name="failover-secret"></a>

This example shows how to configure failover to a different secret (not a replica):

```
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: aws-secrets
spec:
  provider: aws
  parameters:
    region: us-east-1
    failoverRegion: us-east-2
    objects: |
      - objectName: "arn:aws:secretsmanager:us-east-1:777788889999:secret:MySecret-a1b2c3"
        objectAlias: "MyMountedSecret"
        failoverObject: 
          - objectName: "arn:aws:secretsmanager:us-east-2:777788889999:secret:MyFailoverSecret-d4e5f6"
```

## Additional resources
<a name="additional-resources"></a>

For more information about using ASCP with Amazon EKS, see the following resources:
+ [Using Pod Identity with Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)
+ [Using AWS Secrets and Configuration Provider](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_ascp_csi.html)
+ [AWS Secrets Store CSI Driver on GitHub](https://github.com/aws/secrets-store-csi-driver-provider-aws)