How to Use the GitHub Actions OIDC AWS Deploy Prompt to Retire Static Access Keys

Long lived AWS access keys in GitHub secrets are a breach waiting to happen. OIDC lets GitHub Actions request short lived credentials from AWS with a trust policy you can actually audit. The GitHub Actions OIDC to AWS IAM Deploy Role Planner: Trust Policy, Permissions Boundary, Environment Protection Rules, and a Least Privilege Action Map prompt designs that path: issuer claims, IAM trust policy sketches, permissions boundaries, environment protection rules, and a least privilege action map for the jobs that deploy.

What the prompt produces

1. An OIDC checklist for audience and subject claims.
2. A trust policy sketch conditioned on your repo and refs.
3. Permissions boundary guidance so the role cannot outgrow org rules.
4. A least privilege action map per deploy step for ECR, ECS, S3, or whatever you named.
5. GitHub Environment protection rules for staging versus production approvers.
6. A workflow outline with id-token write and role assumption.
7. A verification checklist including CloudTrail proof.
8. A failure FAQ for bad tokens, fork PRs, and environment mismatches.

How to fill the inputs

RepoAndRefs should list the org/repo and the branches or tags that may deploy. Production should not accept every feature branch.

AwsTargets needs account, region, and services. Vague "cloud stuff" produces vague IAM.

EnvironmentsAndApprovers is where you lock production behind human review. Name the GitHub team that must approve.

OidcProviderState should say whether token.actions.githubusercontent.com already exists so you do not create duplicates.

PermissionsBoundary if your org mandates one. If not, say none and the prompt still warns against wild IAM.

Reading the example output

The sample wires acme-labs/payments-api into account 111122223333 for ECR, ECS, and a docs bucket.

• Trust policy StringLike limits sub to main and version tags.
• Boundary keeps PassRole and S3 scoped.
• Production environment requires two SRE reviewers.
• FAQ explains why fork pull requests should not assume prod.

Tips for better results

• Separate staging and production roles when the blast radius differs.
• Delete static keys only after CloudTrail shows successful AssumedRoleWithWebIdentity.
• Keep workflow permissions at id-token write and contents read unless you truly need more.

Mistakes to avoid

• Do not widen sub to all repos in the org "for convenience."
• Do not grant iam:CreateUser or unbounded s3:* to a deploy role.
• Do not invent thumbprints or managed policy ARNs; confirm in the IAM console.

Who it is for

Platform engineers, security partners, and app teams retiring access keys from Actions.

Related PromptDig links

Open the GitHub Actions OIDC to AWS IAM Deploy Role Planner: Trust Policy, Permissions Boundary, Environment Protection Rules, and a Least Privilege Action Map prompt with your repo and AWS targets. For more coding prompts, Browse more prompts. If your OIDC trust policy survived an audit, Share a prompt.

A practical rollout order

Start in a non production AWS account or a staging role. Create or confirm the OIDC provider, attach the trust policy to a staging role, and run a workflow that only calls sts:GetCallerIdentity. When CloudTrail shows AssumedRoleWithWebIdentity from your repo, add ECR permissions, then ECS update, then any S3 docs sync. Keep production behind environment reviewers until staging has run clean for a full release cycle.

Document the role ARNs in your runbook next to the GitHub Environment names. When someone asks why a fork PR cannot deploy, point at the subject condition instead of temporarily widening trust.

What good looks like after a week

• No AWS_ACCESS_KEY_ID left in repository secrets for deploy jobs.
• Production deploys require the reviewer team you named.
• A failed assume role on a random branch is expected and loud, not silently falling back to keys.
• Permissions boundary denials appear in CloudTrail when someone tries to grow the role past org policy.

If you need a second pair of eyes, paste the trust policy sketch and the action map into your security review ticket with the repo URL and environment names filled in.