◇ OpenCyber Academy
Postgraduate · Chapter 2 · English

Chapter 2 — Cloud and container security: current practice

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 2 — Cloud and container security: current practice

Lesson map

Lesson 02 published. Map, example, EX006.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Workload security"]
  N2["2.2 Identity"]
  N3["2.3 Posture management"]
  N4["2.4 Supply chain for images"]
  N5["2.5 Shared responsibility"]
  N6["2.6 Where Beacon differs"]
  N7["2.7 Critical view"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX006"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Workload security"]
  N2["2.2 Identity"]
  N3["2.3 Posture management"]
  N4["2.4 Supply chain for images"]
  N5["2.5 Shared responsibility"]
  N6["2.6 Where Beacon differs"]
  N7["2.7 Critical view"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX006"]

[Learning outcomes]
    |
    v
[2.1 Workload security]
    |
    v
[2.2 Identity]
    |
    v
[2.3 Posture management]
    |
    v
[2.4 Supply chain for images]
    |
    v
[2.5 Shared responsibility]
    |
    v
[2.6 Where Beacon differs]
    |
    v
[2.7 Critical view]
    |
    v
[Worked example] --> [Exercise EX006]

Learning outcomes

You will (1) survey current practice in workload security, identity and posture management; (2) relate practice to standards; (3) identify where Beacon differs; (4) judge practice critically.

2.1 Workload security

Kubernetes now provides Pod Security admission with Privileged, Baseline and Restricted profiles applied by namespace labels. Many organisations add a policy engine for custom rules. NIST SP 800-190 remains the reference for container risk areas: image, registry, orchestrator, container and host. These areas give Inês a checklist for Beacon's estate: whether images are trusted, whether the registry is controlled, whether the orchestrator enforces safe settings, whether containers run with limited rights, and whether hosts are protected. The audit finding sits in the orchestrator area, where admission decides what may run.

2.2 Identity

Current practice favours federated human access with multi-factor authentication and workload identity for services, issuing short-lived credentials instead of stored keys. NIST SP 800-210 and SP 800-207 provide the access control and zero trust framing. Short-lived credentials mean a leaked token stops working quickly, while a stored key can be used until someone notices and revokes it. Beacon already uses workload identity in two clusters, so Inês knows the approach works in its environment and can be extended to the others. The access control framing helps her explain to engineers why service identities need the same care as human ones.

2.3 Posture management

Organisations continuously compare cloud configuration with benchmarks such as the CIS Benchmarks and control catalogues such as CSA CCM v4, alerting on drift. Continuous comparison catches drift between audits, which is exactly what Beacon lacked: Pod Security labels went missing during an upgrade and nobody noticed until the audit. Beacon already checks its cloud accounts this way but not its clusters, which is one of the three gaps the platform team agrees to close. Inês asks for alerts on cluster drift to go to the platform team's queue rather than a shared mailbox.

2.4 Supply chain for images

Signing images, verifying at admission and keeping images in private registries are increasingly common, along with scanning and inventories of components. Signing lets the cluster check at admission that an image was built by Beacon's own pipeline and has not been changed since. A private registry limits Beacon's clusters to images its own pipeline has stored. Beacon has no image signing yet, so this becomes one of the top three gaps in the platform team's plan, alongside Pod Security labels everywhere and cluster posture checks. Inês notes which parts the policy engine in option B would enforce.

2.5 Shared responsibility

Provider documentation from AWS, Microsoft and Google stresses that customers own workload and identity configuration; Google's "shared fate" language adds provider responsibility for secure defaults. For Beacon, this means the audit finding cannot be passed to the provider: the missing labels were Beacon's configuration. Shared fate suggests providers should make secure defaults easier, but customers still have to choose and keep them. Inês cites each provider's page in the control record, so auditors can see where Beacon's responsibility begins.

2.6 Where Beacon differs

Beacon has workload identity in two clusters, no image signing, posture checks on accounts but not clusters, and incomplete Pod Security labels. Comparing Beacon with current practice turns a long list of possible improvements into specific gaps. Inês presents the comparison as a table with current practice, Beacon's state and priority, so the platform team can agree which gaps to close first. The table also shows strengths, such as workload identity in two clusters, which can be extended rather than built from nothing.

2.7 Critical view

Practice is shaped by vendors; Inês distinguishes what standards require from what products market. For example, runtime monitoring is heavily marketed, but no standard Beacon follows requires it for its risk level, which is one reason option C was not chosen. Inês checks each claimed practice against the standard behind it, such as NIST SP 800-190 or CSA CCM v4, before adding it to the gap table. Where only vendor material supports a practice, she labels it as such, so the committee can weigh it accordingly.

Learning from peers

Inês joins a regional cloud security practitioners' group where members share anonymised practices. Several insurers report the same upgrade gap, which reassures Beacon's board that the problem was common, while reminding Inês that common does not mean acceptable.

Worked example

Inês presents a gap table to Beacon's platform team: current practice, Beacon's state and priority. The team agrees the top three gaps: Pod Security labels everywhere, cluster posture checks and image signing.

Synthetic case. Beacon's state is synthetic.

Errors and limits

"Common practice" is not necessarily good practice; check evidence.

Exercises

Synthesis

Compare practice with standards and with your own estate.

Continue studying — chapter 02 of 12

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