Secrets and OIDC

Secrets, environments and federation

Store credentials as encrypted secrets (repository, environment or organisation level); they are masked in logs and not passed to workflows triggered from forks. Better still, avoid long-lived cloud keys entirely: with OpenID Connect (OIDC), a job requests a short-lived token from GitHub (permissions: id-token: write) and the cloud provider (AWS, Azure, Google Cloud) exchanges it for temporary credentials, with trust conditions on repository, branch or environment. Scope deployment secrets to protected environments.

Deploying to AWS with OIDC (sketch)

Not linted or run here; check the GitHub Actions documentation for current syntax. The role ARN is a placeholder.

permissions:
  id-token: write     # allow requesting the OIDC token
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-deploy
          aws-region: ap-south-1
      - run: aws s3 sync dist/ s3://example-site --delete

Restrict the trust policy

Allow the cloud role only for your repository and the specific branch or environment, never for any repository.

Quick check: What advantage does OIDC give over storing cloud keys as secrets?

• No need for permissions
• Faster builds
• Free cloud usage
• Short-lived credentials with no long-lived key to leak