Kubernetes secret contracts

Open My Learning →

1. 01 · Book chapter

   Define who may observe secret properties ↗

   Treat validation status and Secret access as separate information boundaries.

   Put it to work

   List a contract author, workload author, operator identity, and status reader. Explain which secret properties each may infer and which namespaces they may access.

   Keep as evidence: An authorization matrix using synthetic resources and explicit namespace boundaries.

2. 02 · Book chapter

   Make contract semantics unambiguous ↗

   Separate required secret material, per-key validation, and optional mutation policy.

   Put it to work

   Draft a contract for two keys. Describe missing, empty, invalid, and valid inputs; distinguish omitted policy fields from explicit false values.

   Keep as evidence: A decision table and a manifest labelled as a proposed API example.

3. 03 · Book chapter

   Interpret observations before trusting status ↗

   Distinguish absence, denied access, and a failed observation without leaking raw errors.

   Put it to work

   Trace NotFound, Forbidden, and timeout responses. Decide which conditions can be reported and how old positive status should be treated.

   Keep as evidence: A reconcile timeline with generation, observation outcome, and sanitized reasons.

4. 04 · Book chapter

   Place enforcement in the deployment path ↗

   Connect validation evidence to the component that actually decides whether deployment proceeds.

   Put it to work

   Sketch a CI or GitOps gate. Describe stale generations, unavailable observations, and an explicit bypass policy without treating a condition as automatic admission control.

   Keep as evidence: A gate decision table and the exact point where the deployment is stopped.

   Practice in the browser

   Reject stale deployment evidence →

5. 05 · Book chapter

   Diagnose a failed contract safely ↗

   Investigate permissions, contract state, and consumer readiness without dumping credentials.

   Put it to work

   Write an incident sequence for a contract that becomes unsatisfied after rotation. Record observations before proposing a workload change.

   Keep as evidence: A reversible runbook containing static reasons and synthetic examples only.

Pause and check

Explain the secret and deployment boundaries

Choose an answer for every scenario, then check your reasoning. Progress is saved only in this browser.

1. A user cannot read a Secret but can repeatedly change contracts and inspect validation status. What risk remains?

None, because raw values are hidden They may infer secret properties through validation outcomes Every contract automatically grants Secret access

Explanation and further reading

Validation can be an information oracle. Contract authorship and status visibility need authorization even when the operator never prints a value.

Revisit the guide or chapter →

2. An operator has list and watch permission on Secrets. How should that access be treated?

As potentially exposing Secret contents within its permitted scope As metadata-only by definition As harmless because the README says read-only

Explanation and further reading

Read-only is still privileged access to secret material. Namespace scope and identity permissions belong in the threat model.

Revisit the guide or chapter →

3. In the book's canonical contract semantics, a required Secret is absent. Can per-key nonEmpty settings make the contract satisfied?

Yes, if all nonEmpty fields are false Yes, if injection is disabled No, the required Secret must exist

Explanation and further reading

Secret existence is distinct from per-key rules. Optional mutation policy does not waive the requirement that the declared material exists.

Revisit the guide or chapter →

4. A policy defaults to true but must accept an explicit false. What must the API representation preserve?

Only a boolean without presence information The difference between omission and an explicit false The order of YAML fields

Explanation and further reading

Defaulting must not erase a caller's explicit choice. The proposed API uses presence-aware fields where these meanings differ.

Revisit the guide or chapter →

5. Reading a Secret returns Forbidden. Which status interpretation is appropriate?

The Secret definitely does not exist The contract definitely passed Access was denied; report a separate sanitized reason

Explanation and further reading

Forbidden and NotFound indicate different observations. Conflating them hides an authorization or installation problem.

Revisit the guide or chapter →

6. The last observation was positive, but the current API read timed out. What should a gate avoid?

Treating the old positive result as a fresh successful observation Recording that observation failed Checking the contract generation

Explanation and further reading

A failed observation must not silently refresh old evidence. A deployment gate needs status freshness and the relevant generation.

Revisit the guide or chapter →

7. The controller evaluates identical observed inputs twice. What should the second pass avoid?

Reporting the same logical result Unnecessary status writes and repeated workload mutations Checking current authorization

Explanation and further reading

Reconciliation should be idempotent. Calculate the intended result and publish actual changes instead of assuming each event requires a mutation.

Revisit the guide or chapter →

8. A Secret receives a label update without a value change. What can its new resourceVersion alone establish?

The credential definitely rotated Every consuming process loaded a new password The Kubernetes object changed; credential rotation is a separate observation

Explanation and further reading

Object changes, synchronization, and business credential rotation are different events. Keep their evidence separate.

Revisit the guide or chapter →

9. A contract reports a positive condition. Does that condition alone stop an unrelated deployment when it becomes false?

No, enforcement must be placed in the actual deployment path Yes, every custom-resource condition is admission control Yes, any controller status automatically blocks CI

Explanation and further reading

Status is evidence, not automatic enforcement. Identify the CI, GitOps, or admission component that makes the deployment decision.

Revisit the guide or chapter →

10. A rotation incident needs investigation. Which evidence belongs in a shared incident report?

Raw Secret YAML including values Sanitized reasons, resource identities, generations, and observed consumer state A live password to help reviewers reproduce it

Explanation and further reading

An operational runbook should preserve useful observations without turning reports into another secret distribution channel.

Revisit the guide or chapter →

Your checklist is saved only on this device. Keep your own evidence alongside each exercise. Follow new guides →