◇ OpenCyber Academy
Engineering · Chapter 21 · English

Chapter 21 — Cloud and container security: requirements

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 21 — Cloud and container security: requirements

Lesson map

Lesson 21 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["21.1 Good requirements"]
  N2["21.2 Sources"]
  N3["21.3 Examples"]
  N4["21.4 Prioritising"]
  N5["21.5 Exceptions"]
  N6["21.6 Verification link"]
  N7["21.7 Change control"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["21.1 Good requirements"]
  N2["21.2 Sources"]
  N3["21.3 Examples"]
  N4["21.4 Prioritising"]
  N5["21.5 Exceptions"]
  N6["21.6 Verification link"]
  N7["21.7 Change control"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]

[Learning outcomes]
    |
    v
[21.1 Good requirements]
    |
    v
[21.2 Sources]
    |
    v
[21.3 Examples]
    |
    v
[21.4 Prioritising]
    |
    v
[21.5 Exceptions]
    |
    v
[21.6 Verification link]
    |
    v
[21.7 Change control]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) write testable security requirements for meterhub; (2) derive them from risks, standards and regulation; (3) prioritise them; (4) link each to verification.

21.1 Good requirements

A requirement says what the system must do in a way that can be tested: "Pods in production namespaces must not run as root" is testable; "the cluster must be secure" is not. Each requirement names its scope, condition and expected behaviour.

Scope says where the requirement applies, such as production namespaces only; the condition says when, such as at admission; the expected behaviour says what must happen, such as rejection of the pod. With all three, two engineers reading the same requirement would write the same test. Without them, one might check only new pods and another every running pod, and both would claim the requirement was met while measuring different things.

21.2 Sources

Risks from the key-leak review, the Kubernetes Pod Security Standards, CIS Benchmark recommendations for managed Kubernetes, CSA CCM v4 controls and the energy regulator's data rules. Each requirement cites its source so its purpose is clear.

Citing the source protects a requirement from being quietly dropped. If a developer asks why pods cannot run as root, the answer points to the Pod Security Standards and to the opening incident review, not to someone's preference. Sources also show when a requirement may need revisiting: a new CIS Benchmark version or a change in the regulator's rules flags every requirement drawn from it for review.

21.3 Examples

R1: workloads obtain cloud credentials only through workload identity with lifetimes under one hour. R2: every production namespace has a default-deny ingress and egress network policy. R3: production namespaces enforce the Restricted Pod Security profile. R4: only images signed by the pipeline are admitted. R5: storage holding readings cannot be made public. R6: high-risk configuration changes raise an alert within 15 minutes.

Each example is phrased so a machine or a person can check it. R1 names a mechanism and a lifetime; R2 names a policy type and a scope; R4 states what the admission controller must refuse. Elena writes R5 as an outcome rather than a mechanism, because the provider offers several ways to block public storage and the team should be free to choose the one that suits each account.

21.4 Prioritising

Requirements are ranked by risk reduced and effort. R1 and R5 directly address the opening case; R2 addresses the missing network policies.

R1 removes the kind of long-lived key that leaked; R5 stops readings from being exposed even if access settings are later misconfigured. Both directly prevent a repeat of the opening incident. R2 follows because flat networking would let a single compromised pod reach the database. Lower-ranked requirements still matter but can wait until the most direct risks are closed.

21.5 Exceptions

Some workloads, such as the node agent, need privileges. Requirements allow documented, time-limited exceptions approved by the platform lead.

Time limits force a review: an exception granted for six months must be justified again, so temporary needs do not become permanent holes. Documentation records why the workload needs the privilege and what compensating controls apply, such as running the node agent only on dedicated nodes. Approval by the platform lead makes one person accountable for each exception. Expired exceptions fail the admission check automatically.

21.6 Verification link

Each requirement has a verification: an admission test, a configuration query, or an alert test with synthetic events.

An admission test tries to deploy a non-compliant pod and expects rejection. A configuration query lists every namespace and checks for the default-deny policy. An alert test injects a synthetic event, such as a public storage change in the test account, and measures how fast the alert arrives. Each method produces a recorded result that can go into evidence. Results are stored with dates and versions.

21.7 Change control

Requirements change only through review, with the reason recorded.

Without review, requirements drift as people bend them to fit what was built. Recording the reason for a change helps later readers understand whether it reflected new risk information or simply convenience. When a requirement changes, its verification is updated at the same time, so tests always match the current version. Rosa approves requirement changes, and each change gets a short entry in the requirements file history explaining what changed, why, and which tests were updated alongside it.

Ownership

Each requirement has an owning team responsible for meeting and evidencing it.

Worked example

Developers object that R3 will break two services that write to their root filesystem. Elena and the developers agree a two-month exception while the services are changed to write to a mounted volume; the exception expires automatically.

Synthetic case. Requirements and services are synthetic.

Errors and limits

Requirements that nobody can meet get ignored; plan exceptions and timelines.

Exercises

Synthesis

Testable, sourced requirements anchor the engineering work.

Continue studying — chapter 21 of 50

← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →