Chapter 8 — Cloud and container security: difficult cases
Lesson map
Lesson 08 published. Map, example, EX036.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Legacy batch"]
N2["8.2 Vendor agent"]
N3["8.3 Incident pressure"]
N4["8.4 Analytics notebooks"]
N5["8.5 Exceptions register"]
N6["8.6 Expiry"]
N7["Patterns across cases"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX036"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Legacy batch"]
N2["8.2 Vendor agent"]
N3["8.3 Incident pressure"]
N4["8.4 Analytics notebooks"]
N5["8.5 Exceptions register"]
N6["8.6 Expiry"]
N7["Patterns across cases"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX036"]
[Learning outcomes]
|
v
[8.1 Legacy batch]
|
v
[8.2 Vendor agent]
|
v
[8.3 Incident pressure]
|
v
[8.4 Analytics notebooks]
|
v
[8.5 Exceptions register]
|
v
[8.6 Expiry]
|
v
[Patterns across cases]
|
v
[Worked example] --> [Exercise EX036]
Learning outcomes
You will (1) handle conflicts between enforcement and operations; (2) manage legacy workloads; (3) decide under pressure; (4) document exceptions.
8.1 Legacy batch
Claims batch jobs run as root using an old image. Rewriting takes months. Inês grants a time-limited exception with compensating controls: dedicated nodes, no network access beyond the database, and monitoring. The compensating controls reduce what a compromise of the batch jobs could reach: dedicated nodes keep them away from other workloads, limited network access stops them reaching the internet or other services, and monitoring shows unusual behaviour. The exception has an expiry date tied to the rewrite. When the rewrite was incomplete at expiry, the committee extended it once for three months.
8.2 Vendor agent
A vendor monitoring agent needs privileged access. Inês asks the vendor for documentation on why, limits it to its own namespace, and records the exception with annual review. Asking for documentation turns a vendor's request into evidence that can be reviewed. If the vendor cannot explain why privileged access is needed, that is a reason to question the agent itself. Keeping it in its own namespace limits the effect of a compromise. The annual review checks whether a newer version of the agent needs less access, which some vendors introduce over time.
8.3 Incident pressure
During a claims outage, an engineer wants to disable enforcement to deploy a debug pod. The runbook gives a break-glass path: a pre-approved debug namespace at Baseline, logged and removed afterwards. A break-glass path lets engineers act quickly during an outage without disabling the controls that protect customer data. The debug namespace is approved in advance, runs at Baseline, and is logged, so its use can be reviewed afterwards. Removing it after the incident ensures it does not become a permanent gap. The runbook names who may use the path and how its use is reported.
8.4 Analytics notebooks
Analysts need flexible environments. Restricted applies, and common needs are met by preapproved images. Data scientists often install packages and run code that platform teams cannot predict, which is why analytics was a first priority. Pre-approved images give analysts their common notebook tools without needing an exception from Restricted. When an analyst needs something not covered, they request a new image, which is reviewed and added for everyone. Inês checks with the analytics lead that the images cover most daily work, so Restricted does not push analysts towards workarounds.
8.5 Exceptions register
Each exception has an owner, reason, compensating controls and expiry date. Recording all four fields turns an exception into a decision others can check. The owner is the product team that needs the exception, the reason explains why the standard profile does not fit, compensating controls show how risk is reduced, and the expiry forces a fresh decision. The register lives in the central repository, so it is reviewed with policy changes and visible to auditors. Inês checks the register against live cluster labels each month.
8.6 Expiry
Expired exceptions are flagged in the monthly metric. Flagging expired exceptions in the monthly metric means the risk committee sees them, not just the security team. The owner must renew the exception with a fresh reason, close it, or explain the delay. The claims batch exception was flagged at expiry, and the committee extended it once while recording that any further extension requires the risk committee. The metric is designed so that every expiry reaches the committee in the month it falls due. Owners receive a reminder a month before each expiry date.
Patterns across cases
Looking across the cases, Inês notices that each difficult case was easier when a path had been agreed in advance. The break-glass namespace, the exception template and the vendor questionnaire all turned arguments in the moment into routine decisions. She adds a short rule to the programme: when a new kind of difficult case appears twice, write a pre-agreed path for it. This keeps the control firm without forcing people to choose between security and getting work done under pressure.
Reviewing exceptions together
Each quarter, owners present their open exceptions briefly to the working group, which keeps expiry dates visible and spreads good compensating controls between teams.
Worked example
The claims batch exception reaches expiry with the rewrite incomplete. The committee extends it once, for three months, after the team shows progress, and records that further extension requires the risk committee.
Synthetic case. Cases are synthetic.
Errors and limits
Exceptions are part of a good control, not a failure of it, when governed.
Exercises
- EX036 — Batch controls. What compensating controls applied to legacy batch? Rubric: 3 = dedicated nodes, limited network, monitoring; 2 = two; 1 = one; 0 = none.
- EX037 — Vendor. How was the vendor agent handled? Rubric: 3 = documentation, own namespace, annual review; 2 = partial; 1 = vague; 0 = none.
- EX038 — Break-glass. What is the break-glass path? Rubric: 3 = preapproved debug namespace at Baseline, logged, removed; 2 = partial; 1 = vague; 0 = none.
- EX039 — Register fields. What does each exception record contain? Rubric: 3 = owner, reason, controls, expiry; 2 = two; 1 = one; 0 = none.
- EX040 — Extension. How was the batch extension governed? Rubric: 3 = one 3-month extension; further needs committee; 2 = partial; 1 = vague; 0 = none.
Synthesis
Govern exceptions with owners, controls and expiry.
Continue studying — chapter 08 of 12
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →