Chapter 18 — Security architecture | Engineering Cloud and container security

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 18 — Security architecture

Lesson map

Lesson 18 published. Map, example, EX052.

flowchart TD
  N0["Learning outcomes"]
  N1["18.1 Layers"]
  N2["18.2 Trust boundaries"]
  N3["18.3 Isolation choices"]
  N4["18.4 Zero trust alignment"]
  N5["18.5 Architecture decision records"]
  N6["18.6 Guardrails versus gates"]
  N7["Reviewing the architecture"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX052"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["18.1 Layers"]
  N2["18.2 Trust boundaries"]
  N3["18.3 Isolation choices"]
  N4["18.4 Zero trust alignment"]
  N5["18.5 Architecture decision records"]
  N6["18.6 Guardrails versus gates"]
  N7["Reviewing the architecture"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX052"]

[Learning outcomes]
    |
    v
[18.1 Layers]
    |
    v
[18.2 Trust boundaries]
    |
    v
[18.3 Isolation choices]
    |
    v
[18.4 Zero trust alignment]
    |
    v
[18.5 Architecture decision records]
    |
    v
[18.6 Guardrails versus gates]
    |
    v
[Reviewing the architecture]
    |
    v
[Worked example] --> [Exercise EX052]

Learning outcomes

You will (1) design a layered security architecture for meterhub; (2) place trust boundaries; (3) choose isolation levels; (4) document architecture decisions.

18.1 Layers

Account level: separate accounts for production, test and backups; organisation policies that block public storage and restrict regions. Cluster level: private control plane endpoint, workload identity, Pod Security admission at Restricted, default-deny network policies. Workload level: signed images, non-root, minimal capabilities. Data level: customer-managed keys, separation of readings and customer details.

Each layer stops a different class of mistake. Account policies block public storage everywhere, even if a developer creates a bucket carelessly. Cluster settings ensure pods cannot run privileged or talk freely. Workload settings limit what a single container can do. Data controls protect readings even if other layers fail. Together they mean no single error exposes households' data.

18.2 Trust boundaries

Internet to load balancer; load balancer to ingest; ingest to storage; cluster to cloud APIs; pipeline to cluster; production to backup account. Each boundary has authentication and a policy check.

Listing boundaries makes it clear where checks must happen. The pipeline-to-cluster boundary is easy to overlook, yet whoever controls the pipeline can deploy anything. The production-to-backup boundary protects recovery from a compromised production account. Elena marks each boundary on the architecture diagram with its authentication method and policy. Rosa reviews the marked diagram.

18.3 Isolation choices

Namespaces with strict policies for most services; a separate cluster for the payment service; separate accounts for backups. NIST SP 800-190 discusses grouping containers by sensitivity on hosts.

Grouping by sensitivity keeps high-risk workloads away from low-risk ones, so a compromise of a less important service is less likely to reach sensitive data. The payment service's separate cluster means a flaw in a metrics pod cannot touch it. Backups in a separate account survive a compromise of the main account. Elena records the reasons in the design note.

18.4 Zero trust alignment

Every service call is authenticated with workload identity, following NIST SP 800-207, and authorised by policy.

Workload identity gives each service a credential tied to what it is, not where it runs, issued automatically and rotated often. Authorising each call by policy means a service can only perform the actions it needs. Being inside the cluster no longer grants access by default. Denied calls are logged with the caller's identity and the action attempted, which gives investigators a clear trail. Elena tests the policies by sending synthetic calls from an unapproved service and checking that each one is refused.

18.5 Architecture decision records

Each choice is recorded with context, options and consequences, so future engineers know why the payment service is separate.

Without a record, a future engineer might merge the payment service back into the main cluster to save effort, unaware of the reasons it was separated. The record explains the risk and compliance drivers and lists the alternatives considered. If circumstances change, the record shows what to reconsider. Records are short, numbered and stored with the infrastructure code, so they are reviewed in the same pull requests as the changes they explain.

18.6 Guardrails versus gates

Guardrails (organisation policies) prevent classes of mistakes everywhere; gates (pipeline checks) stop specific changes. Both are used.

Guardrails apply broadly and cannot be bypassed by an individual team, such as a policy that forbids public storage in any account. Gates check particular changes and can be more specific, like rejecting an image without a signature. Guardrails give a safety floor; gates give detailed control on the path to production. Elena lists which risks each covers, so no important risk depends on a single gate that a team could skip.

Reviewing the architecture

Architecture reviews happen when a new service is added or a boundary changes. The reviewer walks each trust boundary and asks what authenticates the caller, what policy decides access and what is logged. Gaps become tickets. Elena keeps a one-page architecture diagram current in the repository, with links from each boundary to the decision record that explains it.

Worked example

Reviewing the architecture with Rosa, Elena finds that the pipeline can deploy to both test and production with the same credential. A separate production deployer identity is created, usable only from the main branch after approval.

Synthetic case. The architecture is synthetic.

Errors and limits

Architecture on paper must be verified against what is actually deployed.

Exercises

EX052 — Account layer. Name two account-level controls. Rubric: 3 = separate accounts; block public storage; restrict regions; 2 = one; 1 = vague; 0 = none.
EX053 — Guardrails vs gates. How do guardrails differ from gates? Rubric: 3 = prevent everywhere vs stop specific changes; 2 = partial; 1 = vague; 0 = none.
EX054 — Pipeline finding. What pipeline weakness was found? Rubric: 3 = same credential test and prod; 2 = partial; 1 = vague; 0 = none.

Synthesis

Layer controls and document why each boundary exists.

Continue studying — chapter 18 of 50

← Chapter 17 (draft) · Course chapter index · Chapter 19 (draft) →