{
  "_comment": [
    "The resource policy on the AWS Secrets Manager secret. scripts/setup.sh drops this",
    "_comment key, fills in <POD_ROLE_ARN> with the pod's dedicated EKS Pod Identity role",
    "and calls secretsmanager:PutResourcePolicy with the result.",
    "",
    "This is the only grant the role has on the secret, because the role carries no",
    "identity policy at all (see ../../_shared/pod-identity/role-trust-policy.json). A",
    "resource policy on its own is enough to authorize a principal in the same account",
    "(AWS Secrets Manager User Guide, 'Permissions policies attached to an AWS Secrets",
    "Manager secret', https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_resource-based-policies.html).",
    "",
    "What it deliberately does not grant:",
    "  * no secretsmanager:PutSecretValue or UpdateSecret, so the workload cannot replace",
    "    the ciphertext with one wrapped under a key it chose;",
    "  * no secretsmanager:DeleteSecret or DeleteResourcePolicy;",
    "  * nothing on AWS KMS. Reading this secret decrypts it at rest with the AWS managed",
    "    key aws/secretsmanager, which the service does on the caller's behalf; the",
    "    sample's own key, the one holding the secret's value, is reached only through the",
    "    conditional allow in the key policy, where the attestation condition sits."
  ],
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowThePodRoleToReadTheCiphertext",
      "Effect": "Allow",
      "Principal": { "AWS": "<POD_ROLE_ARN>" },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*"
    }
  ]
}