RBCloud & DevOpsTHE PRACTICAL LEARNING LIBRARY
By Ravindra BagaleResources

CHAPTER 49 / 60

GitHub Actions, OIDC and artifact promotion

Run automated checks without storing long-lived AWS keys in repository secrets.

Concept + practical labBy Ravindra Bagale · ~5 min read · lab time additional

Why and what

A workflow responds to events, runs jobs on runners and performs steps. Permissions control the job token; environment protection can gate deployment. OIDC lets an approved workflow obtain short-lived AWS credentials through a narrowly scoped trust policy.

Course validation workflow

yaml
name: Validate course
on: [push, pull_request]
permissions:
  contents: read
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Validate and build
        run: |
          python3 build.py --check
          python3 build.py

Review and pin actions to verified full commit SHAs for hardened use. The readable major-version example is an instructional starting point, not an immutable supply-chain pin.

OIDC deployment setup

  1. Configure GitHub's OIDC provider in IAM following the current official guide.
  2. Create a deployment role whose trust condition restricts the subject to your exact repository and allowed branch or protected environment, plus the expected audience.
  3. Grant only the deployment actions and resource ARNs needed.
  4. In the deployment job request id-token: write and contents: read as needed.
  5. Use a reviewed AWS credentials action to assume that role, then verify aws sts get-caller-identity before deployment.
  6. Deploy only trusted events; never expose production credentials to arbitrary fork pull-request code.

Artifact promotion

Run tests/build on the same source commit, upload a versioned artifact and deploy it after approval. A later checkout of a moving branch can deploy code different from what passed. Record the commit and artifact digest in the release metadata. For EC2, use SSM or a controlled release transport instead of opening SSH globally to changing runner IPs.

Verify and troubleshoot

A trust-policy error differs from an S3 permission error. Inspect the role subject/environment/branch claim and audience before expanding permissions. Test a permitted branch and a denied branch. Avoid printing full identity tokens in logs.

Assignment

Add a protected staging environment and a health check that fails the release if the homepage is absent. Explain how to roll back the exact previous artifact. No workflow in this package is connected to your AWS account automatically.

Official reference

GitHub OIDC with AWS

Ravindra’s Tip

जिस commit को test किया, उसी artifact को deploy करो। बाद में branch फिर checkout की तो अलग code deploy हो सकता है।

Interview and revision check

What must an OIDC trust policy restrict?

The intended audience and exact trusted repository/branch or protected environment subject. Broad trust can authorize unintended workflows.

Ravindra Bagale · Cloud & DevOps Academy · Handbook and project downloads