GitHub Actions OIDC Practical Guide to Secretless Deployment: How to Establish Keyless CI/CD in 1 Week

1) Problem definition

The most common security debt when automating

AWS/GCP/Azure deployment with GitHub Actions is putting long-term secret key (Access Key/Service Account Key) in the CI secret repository. If a key is leaked, it can be abused indefinitely until it is recovered, and it is difficult to respond to an audit if the rotation cycle is not maintained.

This article was written so that DevOps engineers, backend leads, and security personnel can apply it immediately when adopting GitHub OIDC-based secretless deployment. The scope includes GitHub Actions, cloud IAM integration, and deployment workflow hardening. Excludes application runtime security (code vulnerability scanning/WAAP).

2) Evidence and comparison

Larger than

Approach	Initial build time	Operation costs	Damage radius in case of leak	Audit Response	Recommended
A. Store long-term key in GitHub Secrets	Very short (0.5 days)	Low	(lasts until expiration)	Vulnerable (Rotation/Tracking Manual)	Not recommended
B. OIDC + Short-Term Token (STS/Workload Identity)	Medium (1-2 days)	Low	Small (short TTL, conditional issuance)	Strong (easy to track policies/logs)	Highly recommended
C. Own Vault Broker + Dynamic Credentials	Kim (3 days+)	Medium~High	Small	Strong	Large organizations only

GitHub official documentation recommends the pattern of passing a workflow ID token to the cloud provider via OIDC and issuing short-term permissions conditional on the corresponding token claims (branch, repository, environment). AWS/Azure/GCP can all be operated on the same principle, and the removal of long-term keys itself greatly reduces audit risk.

3) Step-by-step execution method

Step 1. Define trust boundary (branch/environment/repository)
Example: Allow deployment permission only on main branch + production environment. PR/fork only maintains read-only permissions.

Step 2. Configure OIDC provider/federation credentials in Cloud IAM
If AWS, register GitHub OIDC provider, and configure it in the role trust policy. sub/aud exactly constrains the conditions. Example: repo:org/repo:ref:refs/heads/main.

Step 3. Enable id-token permission in workflow
Add below to GitHub Actions YAML.

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-prod-deploy
          aws-region: ap-northeast-2
      - run: ./scripts/deploy.sh

Step 4. Apply environment protection rules (Approvals/Wait Timer)
Turn on GitHub Environment protection, force production to run after at least 1 person approves.

Step 5. Observability/Audit Log Connection
Collect role assumption events from cloud audit logs (e.g. CloudTrail) to determine “which workflow used which permissions and when” Turn it into a dashboard.

4) Pitfalls

• Pitfall 1: Allow sub conditions broadly as wildcards — Prevention: Granularity by branch/environment. Recovery: Reduce condition immediately after role separation.
• Pit ​​2: Leaving workflow permissions to default — Prevention: Declare minimum permissions per job. Recovery: Re-grant only necessary permissions based on failure log.
• Pit ​​3: Not deleting existing long-term keys after OIDC transition — Prevention: Include key destruction in transition completion checklist. Recovery: Disable immediately + trace back recent usage log.

5) Execution Checklist

• Have you specified id-token: write in your production deployment workflow?
• Do you restrict sub/aud by repo/branch/environment in your IAM trust policy?
• Have you discarded all existing long-term keys (Access Key/JSON key)?
• Have you applied the GitHub Environment approval rules (minimum 1 person)?
• Have you applied the principle of least privilege (only APIs required for deployment) to your deployment role?
• Do you check role assumption events in the audit log once a month?

Definition of Done: 0 long-term secret keys in production distribution path, 0 unauthorized permission use events within 30 days, distribution failure rate (permission issues) less than 3%.

6) Reference

• GitHub Docs - About security hardening with OpenID Connect (Confirmed: 2026-02-28)
• GitHub Docs - Configuring OpenID Connect in Amazon Web Services (Confirmed: 2026-02-28)
• AWS IAM User Guide - Create OpenID Connect (OIDC) identity providers (Confirmed: 2026-02-28)
• GitHub Docs - Automatic token authentication (Confirmation: 2026-02-28)
• Microsoft Learn - Use OpenID Connect with GitHub Actions to access Azure resources (Confirmed: 2026-02-28)

7) Author’s perspective

The default value I recommend is Plan B (OIDC + short-term token). Regardless of team size, the security/operations balance is the best, and the difficulty of adoption is lower than exaggerated.

Non-recommendation is a compromise of “I’m in a hurry right now, so I leave the long-term key as is.” Although it is convenient in the short term, the costs of accidents, audits, and handovers continue to increase. However, if you are a large enterprise that requires multiple clouds and complex authority brokerage, it is worth considering plan C (Vault Broker) step by step.