◇ OpenCyber Academy
Professional · Chapter 4 · English

Chapter 4 — Cloud and container security: core methods

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 4 — Cloud and container security: core methods

Lesson map

Lesson 04 published. Map, example, EX016.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 Least privilege analysis"]
  N2["4.2 Role design"]
  N3["4.3 Vulnerability prioritisation"]
  N4["4.4 Workload controls"]
  N5["4.5 Container guidance"]
  N6["Choosing the period"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX016"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 Least privilege analysis"]
  N2["4.2 Role design"]
  N3["4.3 Vulnerability prioritisation"]
  N4["4.4 Workload controls"]
  N5["4.5 Container guidance"]
  N6["Choosing the period"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX016"]

[Learning outcomes]
    |
    v
[4.1 Least privilege analysis]
    |
    v
[4.2 Role design]
    |
    v
[4.3 Vulnerability prioritisation]
    |
    v
[4.4 Workload controls]
    |
    v
[4.5 Container guidance]
    |
    v
[Choosing the period]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX016]

Learning outcomes

You will (1) apply least privilege analysis; (2) use vulnerability prioritisation; (3) apply workload controls.

4.1 Least privilege analysis

Compare what each identity is allowed to do with what it has done over a representative period. Unused permissions are candidates for removal, after checking with owners for rare tasks. At Elmstead the representative period is ninety days of access logs, and the owners are the digital team and Dev. A permission can be unused because it is not needed, or because the task that needs it runs rarely, such as a yearly archive. Checking with owners separates the two, so removing a permission does not break a legitimate task.

4.2 Role design

Role-based access control, described by Sandhu et al. (1996), groups permissions into roles. Hannah aims for one role per workload with only needed permissions. At Elmstead, the permits-app role is shared by the web front end and the worker, which gives the internet-facing front end the worker's permissions too. Splitting roles by workload limits what a compromise of one part could reach. Hannah notes this as a later improvement, since the audit concerns unused permissions first. Rarely used permissions, such as those for a yearly archive job, are placed in separate roles that are granted only when needed.

4.3 Vulnerability prioritisation

Severity scores describe potential impact; the EPSS model of Jacobs et al. (2021) estimates the likelihood of exploitation activity; exposure describes whether the workload faces the internet. Combining them gives a fair order. Severity alone would put CVE-C in the internal worker ahead of a finding in the internet-facing front end, even though exploitation is much less likely. Combining all three factors gives an order that matches the council's real risk. Hannah writes the method down so that others can apply it the same way, and she records the scores used for each finding with their sources and the date each score was checked. The method avoids complex scoring; tiers are easy to explain to developers and auditors, and can be refined later if needed.

4.4 Workload controls

Kubernetes Pod Security Standards define Baseline and Restricted profiles; enforcing Restricted makes containers run as non-root and with fewer privileges, reducing the impact of a vulnerability. For Elmstead, enforcing Restricted in the permits namespace means that a container running as root or requesting extra privileges is rejected before it starts. A vulnerability in permits-web would then give an attacker less power inside the container. Hannah tests enforcement in staging with a synthetic pod that breaks the rules, so the evidence shows the profile works rather than only that it is configured. The digital team confirms that its workloads run under the profile.

4.5 Container guidance

NIST SP 800-190 recommends trusted images, regular rebuilding and limiting container privileges. Hannah's plan applies each recommendation to the permit service. Trusted images come from the council's registry, built by the pipeline from approved base images. Regular rebuilding is what fixes the scanner's findings, since a rebuilt image picks up an updated base. Limiting privileges is achieved through the Restricted profile in the permits namespace. She cites the guidance in her method note, so auditors can see where each practice comes from and judge whether it was applied.

Choosing the period

Hannah chooses 90 days because it covers monthly reporting cycles and two releases. She checks the calendar for less frequent tasks, such as the yearly permit renewal campaign and archive job, and asks owners directly about them.

She also notes that the method depends on the provider's access logs being complete. She confirms that logging was enabled for the whole period before relying on it.

Worked example

Hannah writes a one-page method note combining these approaches. Dev asks why not just fix everything at once. She explains that the team has limited time, and an order based on evidence fixes the most important items first.

Synthetic case. Synthetic.

Errors and limits

90 days may miss yearly tasks; confirm with owners.

Exercises

Synthesis

Combine usage evidence, likelihood and exposure to decide what to fix.

Continue studying — chapter 04 of 12

← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →