Chapter 20 — Cloud and container security: foundational cases
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 Case types"]
N2["20.2 Case A: public storage"]
N3["20.3 Case B: credential in image"]
N4["20.4 Case C: over-privileged pipeline"]
N5["20.5 Comparing"]
N6["20.6 Hindsight"]
N7["Sources of cases"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 Case types"]
N2["20.2 Case A: public storage"]
N3["20.3 Case B: credential in image"]
N4["20.4 Case C: over-privileged pipeline"]
N5["20.5 Comparing"]
N6["20.6 Hindsight"]
N7["Sources of cases"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 Case types]
|
v
[20.2 Case A: public storage]
|
v
[20.3 Case B: credential in image]
|
v
[20.4 Case C: over-privileged pipeline]
|
v
[20.5 Comparing]
|
v
[20.6 Hindsight]
|
v
[Sources of cases]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) study representative cloud security cases; (2) extract causes and lessons; (3) compare them with Westmere; (4) avoid hindsight bias.
20.1 Case types
Common patterns in published incident reviews and research include public storage, leaked credentials in code or images, over-privileged identities and unpatched images. Samuel studies synthetic cases modelled on these patterns.
Synthetic cases let Samuel study the patterns without relying on details of real organisations that may be incomplete or disputed. Each synthetic case is built from causes that appear repeatedly in published reviews, so the lessons transfer even though the companies are invented. Samuel writes each case in the same format: what happened, causes, effects and lessons. The common format makes comparison easier.
20.2 Case A: public storage
A synthetic company's bucket of backups was public for months. Cause: a test setting copied to production. Lesson: account-level blocks and checks before deployment.
Westmere's guardrail blocking public storage at the organisation level is the control this case argues for. It would have stopped the copied test setting from taking effect, whatever the deployment did. A pre-deployment check adds a second layer by catching the setting in review. The case also shows why months of exposure can pass unnoticed: nobody was checking. Samuel's weekly checker and the guardrail together would have both prevented and detected it.
20.3 Case B: credential in image
A synthetic startup pushed an image with a cloud key to a public registry; the key was used to start costly machines. Cause: no secret scanning and long-lived keys. Lesson: short-lived identities and pre-push scanning.
The cloud key in that image had broad rights, so the attacker could start machines and run up costs. Westmere's opening case was similar in mechanism but narrower in effect, because the connection string reached only a test database behind a network rule. Short-lived identities would have removed the secret entirely in both.
20.4 Case C: over-privileged pipeline
A build system with administrator rights was misused after its token leaked. Lesson: narrow pipeline permissions.
Westmere's pipeline role review, scheduled after the role-path lab, addresses this pattern. The lab showed dev-alice's path to cluster-admin through the pipeline, which is expected but must be protected. Administrator rights were given to the build system for convenience, so any deployment could create whatever it needed without asking. Once the token leaked, the attacker had the same convenience. Westmere's deployer role is limited to the cluster namespaces it deploys to, and its tokens are short-lived, which limits a leak to a narrow scope.
20.5 Comparing
Westmere's opening case resembles Case B, without misuse, partly because of network restrictions on the database.
The comparison shows that luck and design both played a part. The network rule was design; the absence of real data in the test database was good practice; the fact that nobody misused the open registry, as far as anyone can tell, may have been luck. Samuel's report distinguishes the three. He also notes that the comparison may flatter Westmere, since the cases were chosen because they went badly.
20.6 Hindsight
Decisions that look wrong afterwards may have been reasonable with what was known. Reviews focus on systems, not blame.
The colleague who configured the registry had a reason at the time: a build server outside the network needed to pull images. The mistake was making whole repositories anonymous instead of giving the build server an identity. Understanding the reason helped the team design a fix that met the original need. Samuel's review report records that reason in one sentence, so readers see the decision in its context and do not conclude that the colleague was careless.
Sources of cases
Good case sources include published incident reviews, regulator reports and academic studies. Samuel prefers sources that describe causes and fixes, not just headlines. For each case, he notes which details are confirmed and which are speculation, and only uses confirmed causes when drawing lessons. Using synthetic composites in teaching avoids naming real organisations while keeping the patterns accurate.
Case discussions
Each case is discussed in a seminar.
Worked example
Samuel builds a table mapping each case's causes to Westmere's controls: Westmere now has account-level storage blocks (A), pre-push scanning in progress (B) and a pipeline role review scheduled (C). The table guides priorities.
Synthetic case. Cases are synthetic composites.
Errors and limits
Cases are selected because they went wrong; they do not show how common problems are.
Exercises
- EX058 — Case B lesson. What is Case B's lesson? Rubric: 3 = short-lived identities, pre-push scanning; 2 = partial; 1 = vague; 0 = none.
- EX059 — Hindsight. What is hindsight bias? Rubric: 3 = judging past decisions with later knowledge; 2 = partial; 1 = vague; 0 = none.
- EX060 — Westmere comparison. Which case resembles Westmere's? Rubric: 3 = Case B; 2 = partial; 1 = vague; 0 = none.
Synthesis
Cases teach patterns; compare them carefully with your own system.
Continue studying — chapter 20 of 40
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →