Chapter 19 — Cloud and container security: scope and theory
Lesson map
Lesson 19 published. Map, example, EX055.
flowchart TD
N0["Learning outcomes"]
N1["19.1 Definition"]
N2["19.2 Isolation theory"]
N3["19.3 Least privilege"]
N4["19.4 Declarative configuration"]
N5["19.5 Shared responsibility"]
N6["19.6 Scope for the course"]
N7["Why theory matters"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX055"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["19.1 Definition"]
N2["19.2 Isolation theory"]
N3["19.3 Least privilege"]
N4["19.4 Declarative configuration"]
N5["19.5 Shared responsibility"]
N6["19.6 Scope for the course"]
N7["Why theory matters"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX055"]
[Learning outcomes]
|
v
[19.1 Definition]
|
v
[19.2 Isolation theory]
|
v
[19.3 Least privilege]
|
v
[19.4 Declarative configuration]
|
v
[19.5 Shared responsibility]
|
v
[19.6 Scope for the course]
|
v
[Why theory matters]
|
v
[Worked example] --> [Exercise EX055]
Learning outcomes
You will (1) define cloud and container security; (2) explain the theories behind isolation, least privilege and declarative configuration; (3) set the scope of the subject.
19.1 Definition
Cloud and container security protects workloads, data and identities on shared, on-demand infrastructure and in containerised platforms. NIST SP 800-145 defines the cloud; NIST SP 800-190 sets out container risks: image, registry, orchestrator, container and host.
For StudyHub, the definition covers the cluster, its images, the registry, the managed database and the identities that tie them together. The opening case touched three of SP 800-190's five risk areas. The definition matters because it decides what Samuel's checker must cover and what lies outside his project.
19.2 Isolation theory
Security depends on separating tenants, workloads and privileges. Clouds use hypervisors and accounts; containers use kernel features; Kubernetes uses namespaces and policies.
Each mechanism has a different strength. Hypervisors and accounts provide strong separation; kernel features are weaker because containers share one kernel; namespaces and policies depend entirely on correct configuration. StudyHub uses all three, with the strongest boundaries between production and everything else. That ranking guides where Westmere places its most important separations: student records sit in the production account, in their own namespace, behind network policies and with Restricted pods. If one layer fails, the others still separate records-api from less trusted workloads.
19.3 Least privilege
Every identity has only needed permissions. Sandhu et al. (1996) formalised role-based access control, which cloud identity systems implement at scale.
The role-path lab earlier showed least privilege failing gradually: each role grant looked reasonable, yet support-cy could reach cluster-admin. Role-based access control makes permissions manageable, but only if roles are designed narrowly and reviewed, as the identity chapter describes. Theory supplies the model; operations must keep it true. Roles drift as people add permissions to fix urgent problems and forget to remove them afterwards. Regular reviews and the graph analysis catch that drift, which is why both appear in Samuel's monthly checks.
19.4 Declarative configuration
Kubernetes and infrastructure-as-code describe the desired state; controllers make reality match. Burns et al. (2016) explain this design. Declarative configuration can be reviewed and checked before it is applied.
For Westmere, declarative configuration means a pod running as root can be caught by a check on the configuration file before it ever runs. The same idea underlies the admission enforcement in the operating systems chapter. Reviewing desired state is cheaper than inspecting running systems after the fact. Reviews of desired state also leave a record of who approved each change.
19.5 Shared responsibility
Provider and customer responsibilities differ by service model, as provider documentation explains.
For managed Kubernetes, the provider secures the control plane while Westmere secures workloads, images and access. The opening case's three findings all fell on Westmere's side. Samuel's diagram from the computing systems chapter marks the boundary for each StudyHub service. The boundary is not fixed across services: with a managed database the provider patches the engine, while with a database run on Westmere's own virtual machines Westmere would patch it. Samuel checks each service's documentation rather than assuming the same split everywhere, and records the result on the diagram.
19.6 Scope for the course
Accounts and identity, networks, registries and images, clusters and workloads, data and logging, operations.
These six areas map onto StudyHub's architecture and onto the opening case. Each later chapter returns to one or more of them. Topics outside the scope, such as the provider's data-centre security, are mentioned only where they affect Westmere's choices. Samuel's checker is organised the same way, with one group of checks per area, so its reports line up with the chapters. When a finding does not fit any area, that is a sign the scope may need extending, and Samuel raises it with Tom.
Why theory matters
Theory explains why controls work, which helps when a new service appears that no checklist covers. For example, knowing that isolation in containers depends on the shared kernel tells Samuel to be cautious about any setting that gives a pod access to the host, even if a checklist does not mention that specific setting. Theory also helps him explain decisions to colleagues who ask why a rule exists.
Worked example
Samuel maps the opening case to NIST SP 800-190's risk areas: the anonymous registry is a registry risk, the connection string is an image risk and missing logs is an orchestration and operations gap. The mapping organises the rest of his project.
Synthetic case. Mapping is for the synthetic case.
Errors and limits
Theories describe ideals; real systems need verification.
Exercises
- EX055 — SP 800-190 areas. Name the five SP 800-190 risk areas. Rubric: 3 = image, registry, orchestrator, container, host; 2 = three; 1 = one; 0 = none.
- EX056 — Declarative benefit. Why is declarative configuration helpful for security? Rubric: 3 = reviewable and checkable before applied; 2 = partial; 1 = vague; 0 = none.
- EX057 — Case mapping. Map the connection string to an SP 800-190 area. Rubric: 3 = image risk; 2 = partial; 1 = vague; 0 = none.
Synthesis
Theory gives structure; practice must verify it.
Continue studying — chapter 19 of 40
← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →