◇ OpenCyber Academy
Bachelor's · Chapter 31 · English

Chapter 31 — Cloud and container security: advanced cases

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 31 — Cloud and container security: advanced cases

Lesson map

Lesson 31 published. Map, example, EX091.

flowchart TD
  N0["Learning outcomes"]
  N1["31.1 Combining weaknesses"]
  N2["31.2 Tracing chains"]
  N3["31.3 Layered fixes"]
  N4["31.4 Container case"]
  N5["31.5 Communicating"]
  N6["31.6 Avoiding blame"]
  N7["Teaching through cases"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX091"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["31.1 Combining weaknesses"]
  N2["31.2 Tracing chains"]
  N3["31.3 Layered fixes"]
  N4["31.4 Container case"]
  N5["31.5 Communicating"]
  N6["31.6 Avoiding blame"]
  N7["Teaching through cases"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX091"]

[Learning outcomes]
    |
    v
[31.1 Combining weaknesses]
    |
    v
[31.2 Tracing chains]
    |
    v
[31.3 Layered fixes]
    |
    v
[31.4 Container case]
    |
    v
[31.5 Communicating]
    |
    v
[31.6 Avoiding blame]
    |
    v
[Teaching through cases]
    |
    v
[Worked example] --> [Exercise EX091]

Learning outcomes

You will (1) analyse complex cloud and container scenarios involving several weaknesses; (2) trace how small issues combine; (3) design layered fixes; (4) communicate complex findings.

31.1 Combining weaknesses

Serious incidents often combine several small issues. In a synthetic case, a developer's laptop token with broad rights, a pipeline role that can assume an administrator role and missing alerting on role assumptions together allow an unreviewed change to production.

No single issue in the case is dramatic. Developers have tokens, pipelines assume roles and some events go unalerted in many organisations. Combined, they let someone with the laptop token reach production without review. Samuel uses the case to show why each small weakness deserves attention, even when it looks harmless alone.

31.2 Tracing chains

Samuel uses the role graph (chapter 6), the model (chapter 21) and logs to trace each step. Each link is a separate fix opportunity.

The role graph shows the path from the developer's token through the pipeline role to administrator. The system model shows where that path crosses a trust boundary without review. Logs show when each step happened in the synthetic case. Each tool reveals a different part of the chain, and together they show where to break it. Samuel lists the fix for each link beside it.

31.3 Layered fixes

Short-lived developer tokens; narrowed pipeline role; alerts on administrator role assumption; required review for production changes. Any one breaks the chain; all together make it robust.

Applying all four means an attacker would need to defeat several independent controls, not one. If a short-lived token were still stolen and used quickly, the narrowed pipeline role would limit what it could reach, and the alert would notify the team. Each fix is cheap, so doing all of them costs little more than doing one.

31.4 Container case

A second synthetic case: a privileged debug pod left running with a host path mount, plus no network policies, plus a service account token mounted by default. Fixes: Restricted pod security, default-deny policies, no automatic token mounting where not needed.

Each weakness in the container case enables the next: the privileged pod with a host mount can read node files, the absence of network policies lets it reach any service, and the mounted token gives it an identity to use. StudyHub's Restricted pods and default-deny policies already address two, and the worked example below addresses the third.

31.5 Communicating

Complex findings are explained as a short story with a diagram, then a table of fixes with owners.

For the cloud team, the story is a few sentences describing each step, the diagram shows the chain on StudyHub's architecture, and the table lists each fix with an owner and date. Managers read the story and the table; engineers use the diagram. Keeping all three short means the message survives a busy week. The diagram is reused in later briefings, and each fix is checked off on it as completed.

31.6 Avoiding blame

The cases show system weaknesses, not individual failure.

The developer whose token appears in the synthetic case followed the team's normal practice at the time. Blaming them would ignore the real causes: broad default token rights, a permissive pipeline role and missing alerts. Focusing on the system makes the fixes stick and keeps people willing to report their own mistakes. Samuel's write-up describes each weakness as a setting or practice and states the change that addresses it. Nobody is named. When presented to the cloud team, this framing led several engineers to mention similar habits of their own, which added two more items to the backlog.

Teaching through cases

Samuel presents both cases to the cloud team as short stories, then asks the team to find the links in StudyHub. Working on their own system makes the lessons concrete, and the team finds the unused token mounts themselves with his script. The session takes an hour and produces four backlog items.

Worked example

Applying the container case to StudyHub, Samuel finds 14 pods that mount service account tokens they never use. Turning off automatic mounting for those pods removes credentials that could have been misused if any pod were compromised.

Synthetic case. Cases are synthetic.

Errors and limits

Fixing one link is good; fixing several protects against unknown links.

Exercises

Synthesis

Trace chains of weaknesses and break several links.

Continue studying — chapter 31 of 40

← Chapter 30 (draft) · Course chapter index · Chapter 32 (draft) →