AWS Cloud & DevOps Tutorial 0/70 lessons ~6 min read Lesson 28“IAM, VPC, EC2, Lambda, ECS, EKS, Terraform, CI/CD, and AWS operations”

GitHub Actions for AWS Deployments

Many TechLearningPro repositories live on GitHub. **GitHub Actions** provides workflows, jobs, runners, reusable workflows, and **environments** with protection rules. The critical

Course progress0%

Focus

15 guided sections

Practice signal

Examples included

Career prep

Interview Q&A included

GitHub Actions for AWS Deployments

AWS Cloud & DevOps Engineering · Lesson 28 · DevOps Automation and IaC

Lesson Overview

Many TechLearningPro repositories live on GitHub. GitHub Actions provides workflows, jobs, runners, reusable workflows, and environments with protection rules. The critical AWS-specific skill in this lesson is authenticating to AWS with OIDC (OpenID Connect)—short-lived credentials via AssumeRoleWithWebIdentity—not long-lived IAM user access keys stored as GitHub secrets.

You will design a secure workflow that builds a container image, pushes to ECR, and deploys to a non-prod environment, with production gated by environment protections. You will constrain the IAM trust policy with sub claims (repo, ref, environment) so a stolen workflow in another repo cannot assume your deploy role. Cross-link /learn/ci-cd-automation for generic Actions vocabulary; this course demands AWS OIDC correctness. Next: Infrastructure as Code with CloudFormation so infra ships through the same identity patterns.

Learning Objectives

By the end of this lesson you will be able to:

Structure workflows, jobs, steps, and permissions (contents, id-token).
Explain GitHub OIDC → IAM role assumption for AWS.
Write trust policies with audience and subject conditions.
Use environments (staging, production) with required reviewers.
Build and push to ECR without static AWS keys.
Deploy to ECS/Lambda conceptually with digests.
Apply reusable workflows for TechLearningPro platform standards.
Limit GITHUB_TOKEN permissions to least privilege.
Handle secrets via GitHub Environments + AWS Secrets Manager—not plaintext keys.
Compare Actions vs CodePipeline for a given repo.
Budget Actions minutes and AWS build-adjacent costs; cleanup OIDC providers/roles if lab-only.
Prevent fork PR abuse of cloud roles.
Align with lesson 25 CODEOWNERS on .github/workflows.
Produce evidence of OIDC-only deploy paths.

Prerequisites

Lessons 24–27 concepts (pipelines, artifacts, CodeBuild comparison)
IAM
ECR
GitHub repo admin rights in a sandbox org
Budget alert in AWS sandbox
Optional: /learn/git, /learn/ci-cd-automation

Detailed Core Concepts

Workflows, jobs, runners

A workflow YAML under .github/workflows/ runs on events (pull_request, push, workflow_dispatch). Jobs run in parallel unless needs: chains them. Runners may be GitHub-hosted or self-hosted. Self-hosted runners that hold cloud privileges are high-value targets—harden or prefer OIDC from GitHub-hosted when possible.

Permissions and id-token

Modern workflows set:

yaml
permissions:
  id-token: write   # required for OIDC
  contents: read

Avoid permissions: write-all. Least privilege on GITHUB_TOKEN reduces blast radius if a step is compromised.

OIDC to AWS (core of this lesson)

Create an IAM OIDC identity provider for GitHub (token.actions.githubusercontent.com) in the AWS account—once per account typically.
Create an IAM role trusted by that provider with conditions on token.actions.githubusercontent.com:aud and :sub.
Workflow uses aws-actions/configure-aws-credentials (official pattern) to exchange the GitHub JWT for temporary AWS credentials.
Credentials expire; no long-lived keys to rotate from a leaky secret store.

Never teach AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY as the default for Actions → AWS in this course.

Subject claim examples (illustrative)

Trust conditions often include forms like:

repo:ORG/REPO:* (too broad for prod—prefer tighter)
repo:ORG/REPO:ref:refs/heads/main
repo:ORG/REPO:environment:production

Verify exact subject formats in current GitHub and AWS documentation when implementing—formats evolve with claims customization. Principle: narrowest sub that still allows intended workflows.

Environments

GitHub environments attach secrets, variables, and protection rules (required reviewers, wait timers, deployment branches). Production deploy jobs should environment: production. Authors should not solely approve their own production deploys when policy forbids it.

Reusable workflows and organization policies

Platform teams publish reusable workflows for build-and-push patterns. Consumers call them with thin wrappers. CODEOWNERS protect both the reusable definitions and consumer call sites. Org rules can require workflows from certain repos only—use when mature.

Deploy patterns

Build on PR (no AWS deploy role, or validate-only role).
On main: OIDC to non-prod role → push ECR → deploy staging.
On workflow_dispatch or tag with environment protection: OIDC to prod role → deploy same digest.

Pass digest between jobs via job outputs or by reading ECR after push—do not rebuild for prod.

Secrets hierarchy

GitHub environment secrets for non-AWS config if needed.
AWS Secrets Manager for application secrets; role retrieves at deploy/runtime.
Never commit keys; never put AWS secret access keys in GitHub secrets if OIDC works.

Fork pull requests

pull_request from forks should not receive identity tokens capable of prod deploy. Prefer pull_request with read-only CI; use pull_request_target only with extreme care (easy to footgun). Default posture: no cloud deploy from forks.

Architecture and Design Diagrams

mermaid
sequenceDiagram
  participant GH as GitHub Actions
  participant OIDC as GitHub OIDC
  participant IAM as AWS IAM
  participant ECR as Amazon ECR
  participant ECS as ECS service

  GH->>OIDC: request JWT (id-token)
  GH->>IAM: AssumeRoleWithWebIdentity
  IAM-->>GH: temporary credentials
  GH->>ECR: push image digest
  GH->>ECS: update service with digest

mermaid
flowchart TB
  PR[PR workflow: test only]
  Main[Main workflow: build + staging]
  Prod[Prod environment job]
  RoleNP[IAM role nonprod]
  RoleP[IAM role prod]

  PR --> Tests[unit lint]
  Main --> RoleNP --> ECR[ECR + staging deploy]
  Prod --> RoleP --> ECS[prod deploy]

mermaid
flowchart LR
  subgraph trust [IAM trust conditions]
    Aud[aud = sts.amazonaws.com]
    Sub[sub matches repo and env]
  end
  GH[GitHub job] --> trust --> Role[Deploy role]

Technical Explanation

Illustrative workflow fragment (OIDC)

yaml
name: enrollment-api-ci
on:
  push:
    branches: [main]
  pull_request:

permissions:
  id-token: write
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: # run project test command

  deploy-staging:
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    needs: test
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/tlp-gha-enrollment-staging
          aws-region: ap-south-1
      - name: Login to Amazon ECR
        uses: aws-actions/amazon-ecr-login@v2
      - name: Build and push
        run: |
          # docker build/tag/push using GITHUB_SHA
          # resolve and record digest

Replace account IDs and action version pins with your org’s approved versions. Verify action docs at implementation time. Pin third-party actions by SHA for supply-chain hardening when policy requires.

IAM trust policy shape (conceptual)

Principal federated via the OIDC provider; condition keys for audience and subject. Add StringEquals / StringLike carefully—StringLike with wide * reintroduces risk. Separate roles for staging vs production with different sub environment claims.

configure-aws-credentials behavior

The official action obtains a JWT and calls STS. Temporary keys appear as env vars for subsequent steps. Limit job steps after auth; avoid running untrusted scripts post-auth on the same job without review.

Reusable workflow sketch

on: workflow_call with inputs for image name and role ARN. Caller workflows pass environment name. Platform owns the callee; product owns callers.

Comparing to CodePipeline

Concern	Actions	CodePipeline
Trigger UX	GitHub-native	AWS console/API + Connection
Identity	OIDC to IAM	Pipeline/Build roles
Artifacts	GH artifacts + ECR/S3	S3 artifact store first-class
Approvals	Environments	Manual approval actions
Org fit	GitHub-centric teams	AWS-centric ops

Practical Implementation or Design Walkthrough

Problem

Secure workflow builds and deploys enrollment API image to AWS without static keys.

Steps

Budget alert on.
Create OIDC provider in sandbox account (if absent).
Create staging role with trust limited to your sandbox repo + environment:staging.
Create workflow with id-token: write; deploy job uses environment: staging.
Push to main; confirm STS assumed role in CloudTrail.
Prove a workflow from a different repo name fails assume role.
Add production environment with required reviewer; separate prod role.
Attempt prod job without approval—blocked.
Record digests; cleanup unused roles if temporary; do not leave Admin roles.

Failure paths

Missing id-token: write → OIDC fails.
Wrong sub → AccessDenied on AssumeRoleWithWebIdentity.
Using access keys “temporarily” → reject in review; delete keys.

Enterprise Real-World Scenarios

Access keys in GitHub secrets forever

Keys leak via logs/forks; rotation neglected. Fix: migrate to OIDC; disable keys; audit CloudTrail.

Wildcards in sub

repo:ORG/*:ref:refs/heads/* lets any repo deploy. Fix: per-repo roles or tight path conditions.

pull_request_target with checkout of untrusted code

Classic privilege escalation. Avoid; use safer patterns.

Self-hosted runner as shared pet

Compromise yields OIDC jobs with org secrets. Harden, isolate, or avoid for prod deploys.

Unpinned actions

Compromised tag moves. Pin by SHA for critical workflows.

Best Practices

OIDC only for AWS auth from Actions.
Narrow trust sub/aud conditions.
Separate staging/prod roles.
Environment protection on production.
Least permissions: on GITHUB_TOKEN.
CODEOWNERS on workflows.
Pin actions by SHA when required.
No cloud deploy from forks.
Digest promotion; no rebuild-for-prod.
CloudTrail review of AssumeRoleWithWebIdentity.
Budget minutes + AWS spend alerts.
Reusable workflows for standards.
Mask secrets; prefer AWS secret stores.
Delete lab roles/providers when done if unused.
Document break-glass without static keys if possible (or tightly vaulted human roles).

Common Mistakes and Anti-Patterns

Long-lived access keys as default.
Over-broad OIDC trust.
write-all permissions.
Prod deploy on every branch push.
Secrets in workflow files.
Ignoring CODEOWNERS for workflows.
Using latest action tags without review.
Assuming fork PRs are safe for OIDC deploy roles.

Troubleshooting and Design Review

AccessDenied on assume role. Decode subject claims (GitHub docs); compare to trust policy; check audience.

Credentials not found in later job. OIDC creds are per-job; re-auth in each job that needs AWS.

Environment wait forever. Reviewers not notified; wrong environment name.

Design review: OIDC only? Trust narrow? Environments set? Digests used? Workflows owned? Budget on?

Interview Questions and Answers

Q1: Why OIDC over access keys? Short-lived, no static secret to leak, scoped by identity claims.

Q2: What permission is required for OIDC? id-token: write (and IAM trust).

Q3: How do you scope roles? Trust policy conditions on repo, ref, environment claims.

Q4: What are GitHub environments? Named deploy targets with secrets and protection rules.

Q5: How to promote same image? Build once; prod job consumes digest; no second build.

Q6: Fork PR risk? Untrusted code; do not grant deploy roles.

Q7: Actions vs CodePipeline? Ecosystem vs AWS-native orchestration; both can be secure with least privilege.

Q8: Why pin actions by SHA? Tag mutability / supply chain.

Q9: Where do app secrets live? AWS Secrets Manager/SSM; not in GitHub if avoidable.

Q10: How does CODEOWNERS help? Workflow changes are privileged—require platform review.

Q11: CloudTrail use? Prove which role was assumed by which workflow identity context.

Q12: Break-glass? Documented human role with MFA—not embedding keys in Actions as the everyday path.

Hands-On Exercises

Exercise: Build a secure workflow that builds and deploys an image

Implement OIDC staging deploy; evidence CloudTrail assume events; deny test from wrong subject; prod environment protection; cleanup; budget proof.

Challenge ADR

Require dual approval for production environment; multi-account roles; forbid static keys org-wide via policy. Discuss reusable workflow migration plan.

Lab evidence checklist

Supplemental deep practice for lesson 28

Practice block 1

Draft an IAM OIDC trust policy narrative that allows only repo TechLearningPro/enrollment-api and environment production to assume the prod deploy role; explain why org-wide wildcards fail the security review.

Practice block 2

Show the workflow permissions block with id-token write and contents read; explain what happens if id-token is missing and how the error presents in Actions logs.

Practice block 3

Demonstrate job outputs passing an image digest from build job to deploy job so production never rebuilds; include a failure case where a developer reintroduces docker build in prod job during review.

Practice block 4

Configure GitHub environment production with required reviewers and deployment branch rules limited to main; describe how workflow_dispatch still respects environment protection.

Practice block 5

Prove with a planned negative test that a workflow in a differently named sandbox repo receives AccessDenied on AssumeRoleWithWebIdentity; capture CloudTrail evidence.

Practice block 6

Pin aws-actions/configure-aws-credentials and amazon-ecr-login by commit SHA per org policy; explain tag-moving supply-chain risk using a TechLearningPro tabletop.

Practice block 7

Separate GITHUB_TOKEN permissions from AWS role permissions; give examples of over-privileged contents: write enabling malicious push after compromise of a step script.

Practice block 8

Design reusable workflow inputs for role ARN, ECR repository, and AWS region; require platform CODEOWNERS on the reusable workflow repository.

Practice block 9

Forbid AWS_ACCESS_KEY_ID in repository secrets via an org policy checklist; migration steps for teams that still have keys: rotate/disable, move to OIDC, audit CloudTrail for key use.

Practice block 10

Handle secrets for the enrollment API DB password via Secrets Manager retrieved by the task role—not injected as plaintext GitHub secrets into the image.

Practice block 11

Explain pull_request versus pull_request_target hazards with a malicious fork scenario attempting to exfiltrate OIDC tokens or secrets; state the default safe posture.

Practice block 12

Map Actions environments to AWS accounts (staging account vs prod account) with different role ARNs; never share one role across both environments.

Practice block 13

Add concurrency groups so enrollment-api production deploys do not overlap; define cancel-in-progress behavior carefully to avoid canceling a running apply mid-flight without a plan.

Practice block 14

Instrument CloudTrail alerts on AssumeRoleWithWebIdentity for the prod role from unexpected repository subjects; on-call responds by disabling the role trust pending review.

Practice block 15

Budget GitHub Actions minutes separately from AWS spend; show how matrix strategies can explode cost and how path filters protect the budget.

Practice block 16

Document break-glass human deploy using IAM Identity Center with MFA and short session—still followed by retroactive Git commit—rather than embedding static keys into Actions 'just this once.'

Practice block 17

Create a reviewer checklist specifically for workflow PRs: OIDC, permissions, environments, pin SHAs, no keys, digest promotion, CODEOWNERS satisfied.

Practice block 18

Compare this lesson's OIDC approach to CodePipeline Connections: both can be secure; interview answer should explain trade-offs without declaring a religion.

Practice block 19

Write a game-day script where staging deploy succeeds and prod environment approval is denied intentionally; verify ECS prod digest unchanged.

Practice block 20

Prepare a two-minute interview story about removing long-lived keys from Actions and the incident class that motivated the change at a learning platform scale.

Enrollment-week rehearsal

Narrate aloud a TechLearningPro incident involving GitHub Actions OIDC deployments: detection signals, which Git SHA and artifact digest are suspect, which IAM principal performed the change, how you halt promotions, how you roll back, and which gate you will add. Include budget and cleanup reminders so labs never leave orphan spend. Cross-check /learn/git and /learn/ci-cd-automation only for vocabulary—keep AWS specifics here. Peer-review your narration for hand-waving. Continue only when the story names concrete AWS services and evidence locations.

Enrollment-week rehearsal

Additional design drill

Write a one-page ADR addendum for GitHub Actions OIDC deployments covering multi-account isolation, dual approval, OIDC-not-keys where relevant, immutable artifacts, observe hooks, and cleanup. List ten binary definition-of-done checks. Map Module 2 targets (Lambda, ECS, ECR, EventBridge, Step Functions, Secrets Manager) into the design. Score yourself on the course rubric axes. Next lesson preview: Infrastructure as Code with CloudFormation.

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Enrollment-week rehearsal

Additional design drill

Lesson Summary

GitHub Actions deploys to AWS safely when workflows use OIDC-assumed roles with narrow subject conditions, environment protections, least token permissions, and digest-based promotion—never long-lived access keys as the standard path. Treat workflow YAML as privileged code under CODEOWNERS.

Next: Infrastructure as Code with CloudFormation brings stacks, change sets, drift, and nested stacks into the same delivery loop.