Gnu Group Learning AcademyGnu Group ↗
DevSecOps Fundamentals · Module 08 of 12

Secure GitHub Actions identity and permissions

Harden CI/CD with least-privilege tokens, explicit permissions, short-lived OIDC credentials, reviewed dependencies and protected deployment environments.

Learning objectives

By the end of this module, you should be able to:

  • Configure the mental model for GITHUB_TOKEN permissions.
  • Explain OIDC-based short-lived cloud authentication.
  • Identify mutable third-party actions and privileged pull-request risks.

Default-deny workflow permissions

Set explicit permissions at workflow or job scope and grant only what steps need. `id-token: write` permits requesting an OIDC token; it does not itself grant cloud resource write access.

Federate instead of storing cloud keys

GitHub OIDC can exchange workflow identity for short-lived provider credentials when the provider trust policy matches repository/workflow claims.

Workflow dependencies are code

Third-party actions execute in the runner context. Review provenance and pin to immutable references according to organizational policy.

Worked example

Least privilege workflow

permissions:
  contents: read
  id-token: write

OIDC token → cloud trust policy → short-lived scoped credential
  • Connect each finding to a concrete risk and control.
  • Preserve evidence so a reviewer can reproduce the decision.
Core lab · account-free

Lab 08 — Audit a workflow

Goal: Detect missing explicit permissions and mutable action references in a synthetic workflow.

Before you start

  • No cloud account required.
  • Core lab uses bash/Python 3 and local files only.
STEP 1

Create workflow

cat > /tmp/workflow.yml <<'EOF'
name: demo
permissions:
  contents: read
  id-token: write
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
EOF
STEP 2

Audit policy

python3 - <<'PY'
s=open('/tmp/workflow.yml').read()
assert 'contents: read' in s and 'id-token: write' in s
mutable='actions/checkout@v4' in s
print('explicit permissions: yes; immutable action reference:',not mutable)
assert mutable
PY
STEP 3

Plan remediation

Replace mutable third-party action tags with organization-approved immutable commit references where required, and document update process.

Verify

  • Explicit permissions are visible.
  • The lab identifies the mutable action reference as a review item.

Expected outcome

  • The learner understands OIDC permission versus provider authorization.

Diagnose / troubleshoot

  • If OIDC fails, inspect token claims and provider trust conditions before adding static credentials.
  • If a workflow needs write permission, grant it only to the job that needs it.
Real-world connection

CI identities are production identities and deserve the same least-privilege design as application identities.

Optional real-tool lab

Optional tool lab — workflow grep/audit

Inspect a real training repository without changing GitHub settings.

Prerequisites

  • Install the referenced open-source CLI only for the optional lab.
  • Use an organization-approved pinned version in real CI; do not blindly use latest.

Cost / risk

  • Expected cloud cost: none. Use only approved repositories and disposable training artifacts.

Warnings

  • Never scan or publish real production secrets in a training lab.
  • Scanner output is evidence for triage, not an automatic statement of exploitable risk.
TOOL 1
grep -R "permissions:" -n .github/workflows 2>/dev/null || true
TOOL 2
grep -R "id-token: write" -n .github/workflows 2>/dev/null || true
TOOL 3
grep -R "uses:.*@" -n .github/workflows 2>/dev/null || true
Avoid these traps

Common mistakes

  • Falling back to a long-lived cloud key when OIDC trust is misconfigured.
  • Granting write-all permissions globally.
  • Running untrusted pull-request code with sensitive credentials.
Knowledge check

Can you connect the finding to the control?

Three concept checks plus one scenario check.

1What does `id-token: write` allow in GitHub Actions?

Requesting an OIDC ID token; external provider permissions are still controlled by trust/role policy.

2Why prefer OIDC for cloud deployment?

It supports short-lived federated credentials instead of stored long-lived cloud secrets.

3Why review third-party action references?

Actions execute code in the runner and are part of the software supply chain.

4Scenario: OIDC authentication fails after a branch rename. What should you inspect?

GitHub OIDC claims and the provider trust policy conditions before considering any static-key workaround.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.