Why deployment credentials should not be permanent

A traditional deployment pipeline stores a long-lived access key and reuses it across workflow runs. Copies of that key or excessive permissions enlarge the impact of a compromise. OIDC lets GitHub Actions present the current run’s identity and obtain temporary cloud credentials. Removing a static key helps, but does not replace role design, precise trust conditions or review of the workflow that will use those credentials.

Review two layers independently. The trust policy defines which GitHub executions may assume a role. The permission policy defines what that role may do in AWS. id-token: write permits requesting an OIDC token; it is not itself authority to create or delete cloud resources. The teaching workflow only calls sts get-caller-identity. This makes it possible to inspect the trust path before adding commands that actually deploy code or change infrastructure.

Bind trust to a particular execution

Configure the provider and role in a test account using the official documentation. Match the expected audience, such as sts.amazonaws.com, and restrict the subject to the permitted repository and context. Named environments use a different subject shape from branch-based jobs. Broad repository wildcards merely move the risk from stored secrets into the trust policy. Scope the role to a particular project and environment and establish production protection rules.

Actions and shell commands are part of the trust boundary. Pin sensitive actions to reviewed commit SHAs and maintain an update process. Our sample uses the SHA shown by the official documentation; a fixed SHA does not eliminate ongoing review. Do not interpolate uncontrolled input directly into shell commands in a credentialed job. External pull requests need a separate access path, especially when production environments are involved.

Test an allowed run, the same workflow from a disallowed context and an operation outside the role’s permissions. The second should fail role assumption; the third should fail resource authorization. If both succeed, revisit trust and permissions. Never print tokens or temporary credentials into logs. A successful run should identify the expected account and role and be traceable to the relevant commit without exposing a secret.

Code example and verification

This educational example demonstrates the implementation path. Check the stated runtime and prerequisites in a test environment; the notes explain what remains before production use.

Identity check only; replace the role and region
name: Check AWS identity
on: workflow_dispatch
permissions:
  contents: read
jobs:
  identity:
    runs-on: ubuntu-latest
    environment: production
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Assume the reviewed AWS role
        uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-demo
          aws-region: eu-central-1
          role-session-name: github-identity-check
      - name: Inspect the caller
        run: aws sts get-caller-identity

This needs a preconfigured role and OIDC provider. With environment production, constrain sub to repo:OWNER/REPO:environment:production and aud to sts.amazonaws.com. Replace the owner, repository and example ARN in the trust configuration. Expect the intended Account and role Arn. No static AWS key is required, and this workflow performs no deployment.

Test authorization before deploying

After verifying identity, add deployment commands with a small resource scope and a defined artifact. Establish rollback and partial-failure behavior before production use. Document role ownership, trust conditions and access revocation. Temporary credentials do not stop an authorized workflow from making a harmful change during their validity. Their main value is shorter secret lifetime and an inspectable relationship between a particular execution and bounded authority.

Implementation checklist

  • Create the OIDC provider and role in a test account first.
  • Constrain audience and subject to the exact environment or branch.
  • Define separate production environment protections.
  • Test disallowed contexts and operations outside the role.

Practical explanations and recommendations are Liyan Knowledge editorial analysis.Sources: GitHub — OIDC in AWS · GitHub — OpenID Connect · GitHub — Security hardening

This Liyan Knowledge article is an editorial synthesis based on the original source.View original source