Chapter 14 — Cloud and container security: methods I
Lesson map
Lesson 14 published. Map, example, EX040.
flowchart TD
N0["Learning outcomes"]
N1["14.1 Benchmarks"]
N2["14.2 Choosing checks"]
N3["14.3 Why each matters"]
N4["14.4 Writing it down"]
N5["14.5 Managed services"]
N6["14.6 Exceptions"]
N7["Version control for the baseline"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX040"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["14.1 Benchmarks"]
N2["14.2 Choosing checks"]
N3["14.3 Why each matters"]
N4["14.4 Writing it down"]
N5["14.5 Managed services"]
N6["14.6 Exceptions"]
N7["Version control for the baseline"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX040"]
[Learning outcomes]
|
v
[14.1 Benchmarks]
|
v
[14.2 Choosing checks]
|
v
[14.3 Why each matters]
|
v
[14.4 Writing it down]
|
v
[14.5 Managed services]
|
v
[14.6 Exceptions]
|
v
[Version control for the baseline]
|
v
[Worked example] --> [Exercise EX040]
Learning outcomes
You will (1) use benchmarks to define a configuration baseline; (2) select checks suitable for small clusters; (3) document the baseline.
14.1 Benchmarks
The CIS Benchmarks give consensus configuration recommendations for platforms including Kubernetes and the main cloud providers. They are long; small teams choose the checks that matter most for their risks. The CIS Kubernetes Benchmark alone contains many recommendations across control plane, nodes and policies, and some apply only to clusters where the operator controls the control plane. A small team that tries to apply all of them at once tends to finish none. Priya instead starts from her risk scenarios and selects the benchmark recommendations that address them directly.
14.2 Choosing checks
Priya picks six checks linked to her scenarios: audit logging on, anonymous access off, a Restricted default for pod security, encryption of secrets at rest, no public API endpoint, and automatic node upgrades. Each of the six checks links to a scenario or earlier finding. Audit logging addresses the client-b gap that would hide misuse; anonymous access off and a private endpoint reduce who can reach the cluster API; the Restricted default stops risky pods; secrets encryption protects stored credentials; and automatic node upgrades keep kernels patched. All six can be read from a settings export without changing anything.
14.3 Why each matters
Audit logging supports investigation; anonymous access off prevents unauthenticated requests; the Restricted default blocks risky pods; secrets encryption protects stored credentials; a private endpoint reduces exposure; auto-upgrades keep nodes patched. Writing one reason per check helps when someone asks to relax it. If a client wants a public endpoint for convenience, the reason, reducing exposure of the cluster API, makes the trade-off visible. The reasons also guide fixes: knowing that auto-upgrades exist to keep kernels patched tells the team that a failing node needs an upgrade plan, not just a setting change.
14.4 Writing it down
The baseline is a small file with each setting and its expected value, kept in the repository with a short reason for each. The file uses the same setting names as the settings export, so a script can compare them directly, as the guided lab does. Each line records the setting, its expected value and one sentence of reason. Keeping it short means Kwame can review the whole baseline in a few minutes, and any proposed change to an expected value is easy to spot.
14.5 Managed services
Some settings are controlled by the provider in managed Kubernetes; the baseline notes which ones Cobalt sets and which it relies on the provider for, citing the provider's shared responsibility page. On a managed cluster, the provider runs the control plane, so some settings are fixed by the provider's own configuration. Priya marks each of the six checks as set by Cobalt or set by the provider, and checks provider settings by reading them from the export rather than assuming. Where a provider controls a setting, the evidence is a link to the provider's documentation plus the value read from the export.
14.6 Exceptions
Where a client needs a different value, the exception is recorded with owner and expiry. An exception without an expiry quietly becomes permanent, so each one has a review date on which the owner must either renew it with a fresh reason or remove it. A recorded exception does not turn a failure into a pass: the check still reports the setting as different from the baseline, and the exception register explains why. Keeping both visible stops the failure count from shrinking simply because exceptions were granted.
Version control for the baseline
Keeping the baseline in the repository means every change to it is reviewed and recorded. If someone wants to relax a setting, the change appears in review with a reason, and Kwame can approve or question it. The history also shows auditors when the baseline was introduced and how it has evolved.
Worked example
Kwame asks why Priya did not include all benchmark items. She shows that her six cover the top scenarios and can be checked automatically today; more will be added once these pass.
Synthetic case. Baseline is synthetic.
Errors and limits
A baseline copied without understanding is followed reluctantly and dropped quickly.
Exercises
- EX040 — Six checks. List Priya's six baseline checks. Rubric: 3 = audit, anonymous off, restricted default, secrets encryption, private endpoint, auto-upgrade; 2 = five; 1 = three; 0 = none.
- EX041 — Selection reason. Why not include every benchmark item at first? Rubric: 3 = focus on top scenarios, automatable now; 2 = partial; 1 = vague; 0 = none.
- EX042 — Provider settings. How are provider-controlled settings handled? Rubric: 3 = noted as relied on, citing shared responsibility; 2 = partial; 1 = vague; 0 = none.
Synthesis
Choose a small, justified baseline and grow it.
Continue studying — chapter 14 of 30
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →