Chapter 20 — Cloud and container security: engineering context
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 The discipline"]
N2["20.2 Stakeholders"]
N3["20.3 Standards"]
N4["20.4 Constraints"]
N5["20.5 Project goals"]
N6["20.6 Success measures"]
N7["Mapping to CCM"]
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 The discipline"]
N2["20.2 Stakeholders"]
N3["20.3 Standards"]
N4["20.4 Constraints"]
N5["20.5 Project goals"]
N6["20.6 Success measures"]
N7["Mapping to CCM"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 The discipline]
|
v
[20.2 Stakeholders]
|
v
[20.3 Standards]
|
v
[20.4 Constraints]
|
v
[20.5 Project goals]
|
v
[20.6 Success measures]
|
v
[Mapping to CCM]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) frame cloud and container security as an engineering discipline; (2) identify stakeholders and constraints; (3) relate standards to Solent's context; (4) define project goals.
20.1 The discipline
Cloud and container security engineering designs, builds and verifies controls for systems built on shared infrastructure, declarative configuration and fast change. Mell and Grance (2011) define the cloud's essential characteristics; each creates security work, such as self-service creating many configuration changes.
On-demand self-service means teams create resources quickly, often without central review. Broad network access means services are reachable from many places. Resource pooling means sharing hardware with others. Rapid elasticity means configurations change constantly. Measured service means costs are visible. Each characteristic brings benefits and a corresponding set of security tasks.
20.2 Stakeholders
Solent's platform team, service developers, the data protection officer, the energy regulator, customers and the cloud provider. Each has constraints: uptime for billing, privacy law, audit requirements.
The platform team wants reliable, maintainable systems; developers want to ship features; the data protection officer wants household data protected; the regulator wants evidence; customers want accurate bills and privacy; the provider sets its own terms. Elena's designs must satisfy all these constraints at once. She keeps a one-page list of each stakeholder's main concern and checks every design decision against it.
20.3 Standards
NIST SP 800-190 for containers; SP 800-210 for cloud access control; SP 800-207 for zero trust; CSA CCM v4 for a control catalogue mapped to many frameworks; CIS Benchmarks for Kubernetes and cloud account settings; Kubernetes Pod Security Standards for workloads.
Each standard serves a purpose. SP 800-190 covers container-specific risks; SP 800-210 covers access control in cloud systems; SP 800-207 sets the zero-trust approach; CCM provides a catalogue mapped to many frameworks; CIS Benchmarks give detailed settings; Pod Security Standards define profiles for workloads. Elena maps meterhub's requirements to these sources.
20.4 Constraints
The platform team has four engineers; changes must not disrupt ingestion; budgets limit new tools; the regulator expects evidence.
Four engineers cannot run a large tool estate, so automation and simple designs are preferred. Ingestion cannot stop, which makes staged rollouts essential. Limited budget favours open tools and built-in cloud features. The regulator's expectation of evidence means every control needs a record showing it works. Elena writes the constraints at the top of her design note, so reviewers can test every proposal against them and reject designs that the small team could not operate.
20.5 Project goals
No long-lived credentials in workloads; default-deny networking in all production namespaces; Restricted pod security everywhere except documented exceptions; signed images only; measurable detection within objectives.
Each goal tackles a cause of past problems: long-lived credentials enabled the key leak; flat networking let any pod reach the database; unrestricted pods could gain broad host access; unsigned images could be swapped. Documented exceptions keep the goals realistic for workloads like node agents. Each goal has an owner on Rosa's team and a target date agreed at the start of Elena's project.
20.6 Success measures
Each goal has a measure, such as percentage of namespaces with default-deny, tracked monthly.
Measures turn goals into progress that managers can track. A rising percentage of namespaces with default-deny shows the rollout is moving. Monthly tracking reveals stalls early. Each measure is defined precisely, such as which namespaces count as production, so different people compute the same number. Elena draws a simple monthly chart for each measure and shares it with Rosa's team and Solent's managers. Where a measure stalls, the chart prompts a question about the cause, such as an exception waiting for approval, rather than blame.
Mapping to CCM
Elena maps the five goals to CSA CCM v4 domains, such as identity and access management, infrastructure and virtualization security, and cryptography, encryption and key management. The mapping helps the regulator see that Solent's plan covers recognised control areas, and shows a gap in logging and monitoring, which Elena adds as a sixth goal: alert on high-risk configuration changes within fifteen minutes.
Worked example
Elena presents the goals to Solent's leadership with a one-year plan. The finance director asks for the cost; Elena estimates mainly engineering time, about 30% of the platform team for two quarters, and no new paid tools.
Synthetic case. Goals and estimates are synthetic.
Errors and limits
Goals without measures cannot be verified.
Exercises
- EX058 — Characteristic link. Give an example of a cloud characteristic creating security work. Rubric: 3 = self-service causes many changes; 2 = partial; 1 = vague; 0 = none.
- EX059 — Five goals. List the five project goals. Rubric: 3 = no long-lived creds, default-deny, restricted, signed images, detection; 2 = three; 1 = one; 0 = none.
- EX060 — Cost. What was the cost estimate? Rubric: 3 = ~30% team for two quarters; 2 = partial; 1 = vague; 0 = none.
Synthesis
Engineering goals need context, standards and measures.
Continue studying — chapter 20 of 50
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →