Use AWS Secrets Manager

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.

Before you begin

Complete the common ESO controller, webhook, CRD, namespace, and permission checks first. For more information, see 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. These examples use namespace qodo. Select your context and replace the namespace consistently:

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:

{
  "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
EKS Pod Identity

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.

aws-secret-store.yaml

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

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.

aws-secret-store.yaml

apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: qodo-secrets
  namespace: qodo
spec:
  provider:
    aws:
      service: SecretsManager
      region: REPLACE_WITH_AWS_REGION

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.

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. 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: Apply the shared target mapping, ownership, rotation, and recovery steps.
AWS Secrets Manager provider: Review provider-specific options and version selection.

Helm charts

Operations

Git Integration

Before you begin

1. Prepare the source Secret

2. Configure the AWS identity and store

3. Reconcile and verify

Troubleshoot AWS access

Next steps

​Before you begin

​1. Prepare the source Secret

​2. Configure the AWS identity and store

​3. Reconcile and verify

​Troubleshoot AWS access

​Next steps

Before you begin

1. Prepare the source Secret

2. Configure the AWS identity and store

3. Reconcile and verify

Troubleshoot AWS access

Next steps