> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qodo.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Use AWS Secrets Manager

> Connect External Secrets Operator to AWS Secrets Manager with IRSA or EKS Pod Identity.

* **Deployment model**: On-premises
* **Configuration reference**: The `external-secrets.io/v1` API.
* **Validation scope**: Manifest/schema checks; AWS and EKS identity execution requires validation in your environment.

Use this page to create the `qodo-secrets` store consumed by the shared Qodo
Secret examples. For more information, see [Manage Qodo secrets with External Secrets Operator](https://docs.qodo.ai/on-prem/external-secrets.md).

## Before you begin

Complete the common ESO controller, webhook, CRD, namespace, and permission
checks first. For more information, see [Before you begin](https://docs.qodo.ai/on-prem/external-secrets.md#before-you-begin).

Prepare your AWS Region, source Secret ARN, an approved IAM role, the ESO
controller's namespace and service account, and access to Secrets Manager and
the identity endpoints used by your selected authentication method. The
referenced-service-account IRSA option also requires ESO permission to request
that account's token.

| Authentication method | Additional prerequisites |
| - | - |
| IRSA | The cluster OIDC provider is configured; the role trusts the referenced Kubernetes service account with audience `sts.amazonaws.com`; ESO can request that account's token |
| EKS Pod Identity | The Pod Identity capability is available on the nodes running ESO, and an association binds the IAM role to the ESO controller's namespace/service account |

For EKS Pod Identity, install the EKS Pod Identity Agent where it is not
already supplied by your cluster mode. Confirm its node coverage before
creating the store. For more information, see [Set up the Amazon EKS Pod Identity Agent](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html).

These examples use namespace `qodo`. Select your context and replace the
namespace consistently:

```bash theme={null}
KUBE_CONTEXT="REPLACE_WITH_YOUR_CONTEXT"
NAMESPACE=qodo
```

## 1. Prepare the source Secret

Using your approved secret-management process, create `qodo-database` in AWS
Secrets Manager. Its JSON value must contain `POSTGRES_PASSWORD` with the
existing database password. Keep actual values out of Git, Helm values, shell
arguments, and chat. Use the correct Region and account for both the source
and the store.

## 2. Configure the AWS identity and store

Reuse your existing approved store when available. Otherwise, have your AWS
administrator create an IAM role scoped to the source secrets. For the paths
in this page, a read policy starts with:

```json theme={null}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetResourcePolicy",
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret",
        "secretsmanager:ListSecretVersionIds"
      ],
      "Resource": "arn:aws:secretsmanager:REGION:ACCOUNT_ID:secret:qodo-*"
    }
  ]
}
```

Replace `REGION` and `ACCOUNT_ID`, and narrow the resource list to your actual
secret ARNs. If the secrets use a customer-managed KMS key, also grant
`kms:Decrypt` on that key and allow the role in the key policy. Additional
features, such as discovering secrets or assuming another role, can require
additional permissions.

Choose one authentication method:

**IRSA**

Configure the role's OIDC trust for service account
`system:serviceaccount:qodo:qodo-secrets-reader` and the expected STS
audience. Replace the example role ARN and Region before applying this
file.

```yaml aws-secret-store.yaml theme={null}
apiVersion: v1
kind: ServiceAccount
metadata:
  name: qodo-secrets-reader
  namespace: qodo
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/qodo-secrets-reader
---
apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: qodo-secrets
  namespace: qodo
spec:
  provider:
    aws:
      service: SecretsManager
      region: REPLACE_WITH_AWS_REGION
      auth:
        jwt:
          serviceAccountRef:
            name: qodo-secrets-reader
```

**EKS Pod Identity**

Associate the IAM role with the ESO controller's service account through
your EKS Pod Identity configuration. This is the operator's identity,
not a Qodo application service account. Ensure the Pod Identity agent is
available on the nodes running ESO.

Save this as `aws-secret-store.yaml`. Do not add `auth.jwt` or
`serviceAccountRef`: ESO cannot impersonate another service account's
EKS Pod Identity association.

For more information, see [EKS Pod Identity setup](https://external-secrets.io/latest/provider/aws-access/#eks-pod-identity-setup).

```yaml aws-secret-store.yaml theme={null}
apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: qodo-secrets
  namespace: qodo
spec:
  provider:
    aws:
      service: SecretsManager
      region: REPLACE_WITH_AWS_REGION
```

```bash theme={null}
kubectl --context "$KUBE_CONTEXT" apply \
  --dry-run=server -f aws-secret-store.yaml
kubectl --context "$KUBE_CONTEXT" apply -f aws-secret-store.yaml
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" \
  wait secretstore/qodo-secrets --for=condition=Ready --timeout=120s
```

If reusing a `ClusterSecretStore`, set `secretStoreRef.kind:
ClusterSecretStore` and its approved name in the examples below. A
namespaced `SecretStore` must be in the same namespace as the `ExternalSecret`.
For more information, see [ESO AWS authentication](https://external-secrets.io/latest/provider/aws-access/).

## 3. Reconcile and verify

Once `qodo-secrets` reports ready, apply the database `ExternalSecret` from
the shared page. It maps `qodo-database.POSTGRES_PASSWORD` to
`qodo-db-admin.POSTGRES_PASSWORD`. A ready store alone does not establish that
it can read that particular Secret or JSON property. For more information,
see [Manage Qodo secrets with External Secrets Operator](https://docs.qodo.ai/on-prem/external-secrets.md).

Verify the ExternalSecret's ready condition, refresh timestamp, target name,
and key names. After source rotation, confirm a new refresh and target update
before restarting the affected Qodo consumer. Run the relevant application
acceptance check after rollout.

## Troubleshoot AWS access

| Symptom | Check and recovery |
| - | - |
| IRSA cannot assume the role | Check the cluster OIDC provider, trust subject and audience, role ARN, and ESO's token-request permission |
| EKS Pod Identity fails with `serviceAccountRef` | Associate the role with the ESO controller's service account and use the store without `auth.jwt` |
| The store is ready but the source cannot be read | Check the source's Region/account, ARN permissions, JSON property, resource policy, and KMS decrypt/key-policy permissions |
| Requests time out | Check access from ESO to the provider and identity endpoints, including any private endpoint policy |

## Next steps

* [Manage Qodo secrets with External Secrets Operator](https://docs.qodo.ai/on-prem/external-secrets.md): Apply the shared target mapping, ownership, rotation, and recovery steps.
* [AWS Secrets Manager provider](https://external-secrets.io/latest/provider/aws-secrets-manager/): Review provider-specific options and version selection.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.