How would you secure GitHub Actions cloud deployments with OIDC instead of long-lived cloud secrets?
Quick Answer
Configure the cloud provider to trust GitHub's OIDC issuer, restrict token claims such as repository, branch, tag, or environment, add `permissions: id-token: write` to the deployment job, and use the cloud provider's official login action to exchange the job JWT for a short-lived cloud token.
Detailed Answer
GitHub Actions OIDC removes the need to store long-lived AWS, Azure, GCP, or Vault credentials as GitHub secrets. The workflow receives a short-lived OIDC token only when the job has id-token: write, and the cloud provider exchanges that JWT for a provider-specific access token after validating issuer, audience, subject, and any configured claim conditions.
The important security design is on the cloud side. Do not trust every repository or every branch from an organization. Bind the provider trust policy to predictable claims such as repository, protected branch, tag pattern, or GitHub environment. When environments are involved, use environment protection rules so production tokens cannot be minted by an unreviewed workflow run.
In the workflow, keep permissions minimal: contents: read plus id-token: write for the job that deploys. Use the official cloud login action where available, and avoid passing the OIDC token to custom scripts unless the provider integration requires it. Also log the cloud identity used by the deploy so incident responders can trace changes back to a GitHub run.
Code Example
jobs:
deploy:
runs-on: ubuntu-latest
environment: production
permissions:
contents: read
id-token: write
steps:
- uses: actions/checkout@v4
- name: Cloud login using OIDC
uses: cloud-provider/login-action@v1
- name: Deploy
run: ./deploy.shInterview Tip
A senior answer emphasizes claim restrictions and environment protection. `id-token: write` only lets the job request a JWT; the cloud trust policy decides whether that JWT can become real cloud access.