Checkpoint Lab — Secrets Management, External Secret Providers, Protected Data, Rotation, and Least-Privilege Patterns

1. Checkpoint goal and acceptance evidence

Prove five independent states:

1. The pipeline/job identity is known: source/ref/SHA, pipeline ID, job ID, runner.
2. An authorized principal can retrieve only the active synthetic secret version.
3. An unauthorized principal is denied and receives no secret file.
4. After rotation v1 → v2, v1 is denied and v2 succeeds for the authorized principal.
5. All temporary secret material is deleted while non-secret evidence remains.

2. Checkpoint pipeline: same provider model, separate authorization outcomes

stages: [verify]

default:
  before_script:
    - set -eu
    - mkdir -p ch07-evidence
    - printf 'source=%s\n' "$CI_PIPELINE_SOURCE" | tee ch07-evidence/context.txt
    - printf 'ref=%s\n' "$CI_COMMIT_REF_NAME" | tee -a ch07-evidence/context.txt
    - printf 'sha=%s\n' "$CI_COMMIT_SHA" | tee -a ch07-evidence/context.txt
    - printf 'pipeline=%s job=%s\n' "$CI_PIPELINE_ID" "$CI_JOB_ID" | tee -a ch07-evidence/context.txt

provider_checkpoint:
  stage: verify
  script:
    - |
      PROVIDER_DIR="$(mktemp -d)"
      trap 'rm -rf "$PROVIDER_DIR"' EXIT
      mkdir -p "$PROVIDER_DIR/versions"
      umask 077
      openssl rand -hex 32 > "$PROVIDER_DIR/versions/v1"
      openssl rand -hex 32 > "$PROVIDER_DIR/versions/v2"
      printf 'v1\n' > "$PROVIDER_DIR/active"

      provider_fetch() {
        principal="$1"; requested="$2"; output="$3"
        active="$(cat "$PROVIDER_DIR/active")"
        if [ "$principal" != 'project/ch07:deploy' ]; then return 77; fi
        if [ "$requested" != "$active" ]; then return 78; fi
        cp "$PROVIDER_DIR/versions/$requested" "$output"
        chmod 600 "$output"
      }

      # 1) Authorized v1 succeeds.
      provider_fetch 'project/ch07:deploy' 'v1' "$PROVIDER_DIR/authorized-v1"
      printf 'authorized_v1=allowed\n' | tee ch07-evidence/results.txt
      printf 'authorized_v1_sha256=%s\n' "$(sha256sum "$PROVIDER_DIR/authorized-v1" | awk '{print $1}')" | tee -a ch07-evidence/results.txt
      rm -f "$PROVIDER_DIR/authorized-v1"

      # 2) Unauthorized principal is denied.
      set +e
      provider_fetch 'fork/untrusted' 'v1' "$PROVIDER_DIR/denied"
      denied_rc=$?
      set -e
      test "$denied_rc" -eq 77
      test ! -e "$PROVIDER_DIR/denied"
      printf 'unauthorized_v1=denied rc=%s\n' "$denied_rc" | tee -a ch07-evidence/results.txt

      # 3) Rotate to v2.
      printf 'v2\n' > "$PROVIDER_DIR/active"

      # 4) v1 is now revoked.
      set +e
      provider_fetch 'project/ch07:deploy' 'v1' "$PROVIDER_DIR/revoked"
      old_rc=$?
      set -e
      test "$old_rc" -eq 78
      test ! -e "$PROVIDER_DIR/revoked"
      printf 'authorized_v1_after_rotation=revoked rc=%s\n' "$old_rc" | tee -a ch07-evidence/results.txt

      # 5) v2 succeeds.
      provider_fetch 'project/ch07:deploy' 'v2' "$PROVIDER_DIR/authorized-v2"
      printf 'authorized_v2=allowed\n' | tee -a ch07-evidence/results.txt
      printf 'authorized_v2_sha256=%s\n' "$(sha256sum "$PROVIDER_DIR/authorized-v2" | awk '{print $1}')" | tee -a ch07-evidence/results.txt
      rm -f "$PROVIDER_DIR/authorized-v2"

  artifacts:
    when: always
    paths:
      - ch07-evidence/context.txt
      - ch07-evidence/results.txt
    expire_in: 1 day

3. Predict the state transitions before running

4. Run on a disposable branch and preserve immutable identity

LAB_BRANCH="ch07/checkpoint"
git switch -c "$LAB_BRANCH"
git add -- .gitlab-ci.yml
git diff --cached --check
git commit -m "ch07: secret lifecycle checkpoint"
LAB_SHA="$(git rev-parse HEAD)"
printf '%s\n' "$LAB_SHA"
git push -u origin "$LAB_BRANCH"

In GitLab, record the pipeline ID, job ID, pipeline source, ref, SHA, runner identity, and job status. Confirm the job SHA equals the recorded LAB_SHA. A green job proves the assertions in this synthetic provider simulation; it does not prove a real provider’s policy or external target state.

5. Inspect the evidence packet without opening secret material

Download or browse only the two evidence text files. Expected result lines resemble:

authorized_v1=allowed
authorized_v1_sha256=<synthetic-digest>
unauthorized_v1=denied rc=77
authorized_v1_after_rotation=revoked rc=78
authorized_v2=allowed
authorized_v2_sha256=<different-synthetic-digest>

The digests prove the synthetic v1/v2 values differ without retaining the values. The denial codes prove policy outcomes in the simulation.

6. Failure injection: stale version or wrong principal

Run exactly one controlled failure before the successful checkpoint:

• Change the first authorized request from v1 to v2 while active is still v1. Expected return 78.
• Or change the authorized principal to project/ch07:build. Expected return 77.

Preserve the failing job ID and non-secret result. Repair only the requested version/principal mapping. Do not broaden provider_fetch policy.

7. Real-world provider mapping and assumptions

If this were Vault/AWS/Azure/GCP/GitLab Secrets Manager, the checkpoint would additionally record:

• provider/offering/tier and exact integration mode;
• GitLab/Runner version assumptions where the feature requires them;
• ID-token audience and expected trust-policy claims (never token value);
• secret logical reference/version and provider policy identity;
• provider audit event or denial status;
• rotation/revocation record and owner.

The course does not require those paid/external systems; this is the architecture mapping only.

8. Incident drill: what if the secret had been real?

Write a short incident note containing these actions in order:

1. Mark the credential as potentially compromised and preserve pipeline/job/source identifiers.
2. Revoke or disable the exposed credential at the authoritative provider.
3. Issue/activate replacement material only for the intended workload.
4. Prove old material is denied and new material succeeds.
5. Review provider/service audit logs for suspicious use during the exposure window.
6. Remove secret-bearing logs/artifacts/caches where authorized and fix the source code/configuration that caused exposure.
7. Document owner, timeline, affected resources, and preventive control.

9. Cleanup and rollback

• The job trap deletes the provider temp directory automatically; the job should not artifact it.
• Delete the disposable ch07/checkpoint branch only after recording its SHA and pipeline/job IDs.
• Remove any synthetic LAB_FAKE_CREDENTIAL project variable or protected lab branch created in Lesson 2.
• Keep only the non-secret evidence packet and assumptions/limitations note.

10. Required evidence packet

11. What Chapter 07 adds to the operating model

You can now separate sensitive-value mechanics from true secret lifecycle. A secure pipeline knows which job identity is authorized, requests only the necessary secret reference, avoids log/artifact exposure, uses short-lived/federated identity where possible, rotates and revokes old material, and preserves non-secret evidence.

Chapter 08 moves into workflow:rules and job rules. That topic becomes much safer once you understand why pipeline-source/ref decisions determine which jobs—and therefore which secret capabilities—can exist at all.

Knowledge check

Official references and version notes

• Pipeline security — current guidance that CI/CD variables are less secure than dedicated secret-management providers and that sensitive values should use stronger secret-management controls where possible.
• CI/CD variables — masking, hiding, protection, fork/MR behavior, file variables, and explicit warnings that masking is not a defense against malicious job code.
• External secrets in CI/CD — current supported provider integrations and tier/offering requirements.
• OIDC authentication using ID tokens — job-scoped ID tokens, audiences, claims, and third-party trust boundaries.
• HashiCorp Vault secrets — id_tokens, secrets:vault, file materialization, and provider-side authorization.
• GitLab Secrets Manager — current limited/beta availability, permissions, branch/environment scoping, Runner requirements, rotation reminders, and file-by-default behavior.
• Secret detection — defense-in-depth for accidentally committed credentials; detection is not a substitute for rotation after exposure.