Configuration and secrets
Version behavioral inputs and rotate credentials through explicit propagation, reload, revocation, and rollback contracts.
On this page
The question for today
What you’ll understand
- Distinguish configuration delivery from application adoption.
- Design credential rotation with a bounded overlap interval.
- Record release inputs without copying credential material into logs.
Configuration edits can change an unchanged binary's behavior, and credentials can expire in an otherwise healthy process. Both belong in the release model. The platform must explain how a value reaches a workload, when the application adopts it, and how old authority is removed. A system that stores values securely but cannot rotate them during a real deployment has solved only part of the operational problem.
Version behavior while limiting sensitive exposure
A ConfigMap carries non-confidential configuration; a Secret is intended for sensitive data. Base64 representation in a Secret is encoding, not encryption. Kubernetes documentation warns that Secrets are stored unencrypted in etcd by default unless encryption at rest is configured. The platform must explicitly establish storage protection, transport protection, access authorization, and audit policy rather than assuming the resource name supplies all four.
Give configuration a stable revision and validate its schema before publication. A timeout changed from milliseconds to seconds can be syntactically valid yet operationally disastrous. Record the revision and the interpreting application version together. For credentials, record a non-secret version identifier or issuance event, not the credential bytes or a casually chosen public fingerprint. The incident question is which authority the workload used, and that can usually be answered without retaining the sensitive material in ordinary logs.
Distinguish delivery, reload, and effective use
A value arriving in a mounted file is not the same as the application using it. Kubernetes projected ConfigMap volumes eventually reflect updates, while values injected as environment variables require a Pod restart to change. A subPath mount does not receive those projected updates. The application may additionally cache a parsed file or hold an existing authenticated connection. State the complete update contract, including what triggers reload and what happens when validation fails.
For a non-secret configuration change, choose either a deliberate restart or a tested reload path. An application can validate a candidate snapshot and swap it atomically rather than exposing partially changed fields. When several values must agree, publish one versioned snapshot instead of separately mutating related keys. Rollback should select a known compatible configuration revision; reverting the binary alone may leave it interpreting an incompatible new setting.
Rotate authority and prove old authority is gone
A planned rotation can issue a new credential, distribute it, confirm adoption, and only then revoke the old one. The overlap window must cover propagation and any connection lifetime that continues to depend on old authority. Too short a window causes outages; an unlimited window leaves obsolete authority alive. The correct choice depends on the credential protocol and revocation behavior, so test it against the actual service rather than assuming all connections are reauthenticated continuously.
Emergency revocation has a different priority: a suspected stolen credential may need immediate invalidation even if some clients fail. Document who can initiate that action and how fresh credentials are obtained without the compromised path. Measure adoption by workload identity and version, not merely by the percentage of files successfully written. Rotation also removes retired credentials from caches, temporary files, and backups according to policy. Do not claim erasure where retention or protocol behavior prevents it.
Work it through
Plan and verify a credential rotation
A platform expects new credentials to reach all clients within ten minutes. Existing connections that depend on the old credential last at most five more minutes. It reserves a three-minute margin. Out of 200 clients, 190 report adopting the new version. Is a twelve-minute retirement safe?
The stated conservative overlap budget is 10 + 5 + 3 = eighteen minutes. A twelve-minute retirement falls six minutes short of that budget.
Reported adoption is 190 / 200 = 95%. Ten clients are still unconfirmed; a high percentage does not establish that every required client can survive revocation.
Inspect those ten identities, their reload path, and their active connection age. If they cannot update, either repair them before planned retirement or explicitly accept and manage the resulting interruption.
After revoking the old credential, test that it is rejected and that new authenticated operations succeed. A successful distribution event alone proves neither condition.
Use at least the stated eighteen-minute budget for this planned case and resolve unconfirmed adoption rather than treating ninety-five percent as complete.
The living notebook
Explore the model
Interactive lab · reliability
Count updated clients without confusing quorum
Treat n as a small fleet and k as clients not yet available after rotation. The panel shows n − k and a mathematical majority. Independent clients do not become safe to revoke merely because a majority updated; the lab models no credential protocol, reload, or revocation propagation.
- Available replicas
- 4 of 5
- Majority needed
- 3
- Majority available?
- Yes
A replica count and a majority threshold, without a consensus protocol. Playback highlights fixed replica states. Having a majority alone does not establish linearizability, durability or failure independence. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forRotation completion is an identity-by-identity contract, not a generic majority threshold.
Pause & reason
Check your understanding
Your turn
Try it yourself
A planned credential rotation has a four-minute propagation bound, a seven-minute connection bound, and a two-minute margin. Calculate its budget. Explain why emergency theft response may deliberately violate this availability-oriented budget.
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Add the three bounds, then identify which objective changes when the old authority is actively compromised.
Compare with the solution
The conservative overlap is 4 + 7 + 2 = thirteen minutes. During active compromise, retaining old authority for thirteen minutes may allow further abuse, so an authorized response may revoke it immediately and accept interrupted clients. Recovery then uses a trusted issuance path. The choice must be explicit, observable, and rehearsed; an emergency cannot be handled by blindly following a planned-rotation timing rule.
Keep the idea
Take it with you
- Protect secrets through explicit controls; encoding is not encryption.
- Track delivery, adoption, and effective connection behavior separately.
- A planned rotation ends with verified revocation, while emergencies can prioritize containment.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.