Chapter 39 — Cloud and container security: maintainability
Lesson map
Lesson 39 published. Map, example, EX115.
flowchart TD
N0["Learning outcomes"]
N1["39.1 Prefer standard features"]
N2["39.2 Policy as code quality"]
N3["39.3 Documentation"]
N4["39.4 Dependencies"]
N5["39.5 Staff changes"]
N6["39.6 Technology change"]
N7["39.7 Technical debt"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX115"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["39.1 Prefer standard features"]
N2["39.2 Policy as code quality"]
N3["39.3 Documentation"]
N4["39.4 Dependencies"]
N5["39.5 Staff changes"]
N6["39.6 Technology change"]
N7["39.7 Technical debt"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX115"]
[Learning outcomes]
|
v
[39.1 Prefer standard features]
|
v
[39.2 Policy as code quality]
|
v
[39.3 Documentation]
|
v
[39.4 Dependencies]
|
v
[39.5 Staff changes]
|
v
[39.6 Technology change]
|
v
[39.7 Technical debt]
|
v
[Worked example] --> [Exercise EX115]
Learning outcomes
You will (1) keep the security platform maintainable; (2) reduce custom code; (3) document decisions; (4) plan for staff changes and technology change.
39.1 Prefer standard features
Built-in Pod Security admission is used instead of custom rules where possible; custom policies cover only what the standard does not. Less custom code means less to maintain.
The built-in admission controller is maintained by the Kubernetes project, documented publicly and tested against each release, so Solent inherits that work for free. A custom rule doing the same job has to be written, tested, upgraded and explained by Solent's own engineers. Elena's test for a new custom policy is simple: name the requirement the standard profiles cannot express. Requiring signed images from Solent's own pipeline passes that test; blocking privileged pods does not, since the Restricted profile already does it.
39.2 Policy as code quality
Policies follow a style guide, have tests and comments explaining intent. Dead rules are removed.
The style guide fixes naming, file layout and how denial messages are worded, so that any engineer can read any policy. Each policy has at least one test that must be admitted and one that must be rejected, which stops a rule from silently matching nothing. Comments state the requirement or threat the rule serves. A rule that never fires might be dead or might be guarding something rare, so it is only removed after its owner confirms the need has gone.
39.3 Documentation
Decision records, runbooks and "why" notes live with the code. A new engineer can understand the platform in a week.
Keeping documents beside the code means a change to a policy and the change to its explanation arrive in the same pull request, where a reviewer can see both. Documents stored elsewhere drift out of date quietly. The one-week figure is tested rather than assumed: the onboarding exercise gives a newcomer a real task and only the written material, and every question they have to ask a colleague marks a gap in the documents.
39.4 Dependencies
The policy engine, GitOps controller and signing tools have upgrade schedules and owners, like any dependency.
These three tools sit in the deployment path, so an outdated version can block releases or carry a known flaw into the admission decision itself. Each has a named owner who tracks its release notes and security advisories and plans upgrades through staging, using the same verification suite as cluster upgrades. Versions are pinned in the GitOps repository, so the record shows which version enforced policy on any given day.
39.5 Staff changes
Two engineers know each component; knowledge is shared through pairing and rotation.
With a single expert, a holiday or a resignation can leave a component nobody dares to touch, and changes then pile up or are made carelessly. Pairing on real changes spreads understanding faster than reading alone, and rotating on-call duty ensures each engineer handles alerts from every part of the platform. Elena keeps a small matrix of components and who can work on each, and a column with only one name is treated as a risk to fix.
39.6 Technology change
If Solent changes cloud provider or Kubernetes distribution, controls defined in standard terms (Pod Security Standards, network policies) move more easily than provider-specific ones.
Provider-specific controls, such as a particular cloud's identity bindings or its storage public-access block, would need rewriting on a new platform, so Elena lists them separately with what each protects. The list turns a vague migration worry into a known amount of work. The standard network policy and pod security definitions would move with only small changes, which is one more reason to prefer them when they meet the requirement equally well.
39.7 Technical debt
A list of known shortcuts with dates for removal is reviewed quarterly.
Each entry records the shortcut, why it was taken, the risk it carries and the date by which it should be gone. A shortcut without a date tends to become permanent. The quarterly review either removes items, extends them with a fresh reason, or raises them as risks if they have become dangerous. The list is visible to everyone, so a newcomer who finds something odd can check whether it is known before assuming it is a mistake.
Retiring controls
Controls are retired when they are replaced or no longer needed, with the reason recorded. For example, a custom rule blocking privileged pods is retired when built-in Pod Security admission covers it, after tests show identical behaviour. Retiring controls carefully keeps the policy set small and understandable. Each retirement goes through the same review as a new control, so nothing is removed by accident.
Review rhythm
Each quarter the team spends one day on maintainability work: removing dead rules, updating docs and upgrading tools.
Worked example
An onboarding test asks a new platform engineer to add a policy for a new requirement using only the documentation. She completes it in two days and suggests three documentation fixes, which are made.
Synthetic case. Platform details are synthetic.
Errors and limits
Maintainability erodes slowly; schedule time for it.
Exercises
- EX115 — Standard features. Why prefer built-in Pod Security admission? Rubric: 3 = less custom code to maintain; 2 = partial; 1 = vague; 0 = none.
- EX116 — Portability. Which controls move more easily between platforms? Rubric: 3 = standard Kubernetes terms; 2 = partial; 1 = vague; 0 = none.
- EX117 — Onboarding test. What did the onboarding test show? Rubric: 3 = 2 days, 3 doc fixes; 2 = partial; 1 = vague; 0 = none.
Synthesis
Maintainable controls outlast the people who built them.
Continue studying — chapter 39 of 50
← Chapter 38 (draft) · Course chapter index · Chapter 40 (draft) →