Chapter 21: Credential & Access Lifecycle
Learning Objectives
By the end of this chapter, you will be able to:
- Keep a registry of every credential the platform runs on - what it grants, every place a copy lives, when it was last replaced - and let a check turn the dates into a failure while there is still time
- Rotate a credential with the shortest gap the platform allows - and say where that gap is - and prove both halves: the new value works, the old one is refused
- Restart what reads a Secret through Git, and explain why
kubectl rollout restarton a Flux-managed Deployment can silently do nothing - Give people access by team, with least privilege, check it with impersonation, and say how long it takes to take it away
- Say when the break-glass kubeconfig may be used, and why its certificate cannot be revoked on its own
Recall Check
Before continuing, quickly recall:
- What does SOPS encrypt in a Secret, and what does a leaked age key open? (Chapter 04)
- Why does a saved Terraform plan or the state count as a secret? (Chapter 02)
- What does Flux do to a change made by hand to an object it manages? (Chapter 03)
If you can’t answer these, revisit the corresponding chapter before proceeding.
Context
Every platform runs on credentials: a cloud token that can delete every server, a key that decrypts every Secret in Git, a password the app signs in with, a token a workflow pushes with. Each one was created once, by someone, and copied to a few places. A credential nobody tracks is replaced only when it leaks - and on that day, the questions are all at once: where are its copies, what reads it, what else did it open, and is the old value really dead?
People are credentials too. Access given to a person is access that has to be taken away one day - and the platform should say how fast that happens.
This chapter makes both a routine: every credential is in a registry with a date and a runbook, and every rotation ends with two proofs - the new value works, the old one is refused. People get access by team and role; the admin kubeconfig is break-glass, not a daily tool.
This chapter shows one widely used way to do it, not every way: credentials in SOPS and CI secrets, rotated by hand on a schedule, and people signing in through an OIDC provider. Others work too:
- a secrets manager with dynamic secrets (Vault, OpenBao) - the database password is created per app and expires by itself; nothing to rotate by hand;
- External Secrets Operator with a cloud secret manager - the value lives outside Git, the cluster fetches it, and rotation happens in one place;
- no long-lived credentials at all where the provider allows it - CI signs in to the cloud with its own OIDC identity (workload identity federation), and people get short-lived certificates (Teleport, a cloud’s IAM).
The story is this platform’s own: a CI artifact that published three of its keys.
Work through each lesson section; the chapter video, once it is published, gives the concept overview.
A Rotation, From Due Date to Proof
