Chapter 8 — Security architecture basics
Lesson map
Lesson 08 published. Map, example, EX022.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Layers"]
N2["8.2 Trust boundaries"]
N3["8.3 Zero trust ideas"]
N4["8.4 Separation of clients"]
N5["8.5 Simplicity"]
N6["8.6 Architecture records"]
N7["Architecture and clients"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX022"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Layers"]
N2["8.2 Trust boundaries"]
N3["8.3 Zero trust ideas"]
N4["8.4 Separation of clients"]
N5["8.5 Simplicity"]
N6["8.6 Architecture records"]
N7["Architecture and clients"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX022"]
[Learning outcomes]
|
v
[8.1 Layers]
|
v
[8.2 Trust boundaries]
|
v
[8.3 Zero trust ideas]
|
v
[8.4 Separation of clients]
|
v
[8.5 Simplicity]
|
v
[8.6 Architecture records]
|
v
[Architecture and clients]
|
v
[Worked example] --> [Exercise EX022]
Learning outcomes
You will (1) describe defence in depth; (2) place controls at layers of a hosting platform; (3) explain trust boundaries.
8.1 Layers
Defence in depth means several controls so one failure does not expose everything. For a client site: network rules, TLS at the proxy, admission rules in the cluster, least-privilege service accounts and logs. Each layer of the client site covers a different kind of failure. Network rules limit who can reach a service, TLS protects traffic in transit, admission rules stop risky pods from starting, narrow service accounts limit what a compromised workload can do, and logs show what happened afterwards. If one layer is misconfigured, such as an outdated image slipping through, the others still reduce the harm and help the team notice it.
8.2 Trust boundaries
A trust boundary is where data passes between areas with different levels of trust, such as internet to proxy or cluster to managed database. Controls cluster at boundaries. Riverside Dental's system has four boundaries that Priya draws in the worked example: internet to proxy, proxy to cluster, cluster to managed database, and cluster to monitoring service. At each point the question is what crosses, who can send it and what checks it. The internet-to-proxy boundary receives the most attention, because anyone can send traffic to it.
8.3 Zero trust ideas
NIST SP 800-207 describes zero trust: no implicit trust based on network location; each request is authenticated and authorised. Cobalt does not need a full programme, but the idea supports checking service identities inside clusters. The unencrypted hop from web to API is an example of implicit trust: it is accepted today because both workloads sit in the same private cluster network. Zero trust would require each service to prove its identity on every request, which is what mutual TLS through a future service mesh would provide. Priya records the gap honestly rather than claiming that the private network makes the hop safe.
8.4 Separation of clients
Cobalt runs each large client in its own cluster and smaller clients in separate namespaces of a shared cluster with network policies between them. Separate clusters give the strongest separation Cobalt offers, but each one costs money and maintenance. Namespaces in a shared cluster are cheaper, so smaller clients such as the two whose workloads were both called web share one cluster. That arrangement relies on network policies, RBAC confined to namespaces and pod security settings. If any of those three is missing, one client's workloads may be able to reach another's.
8.5 Simplicity
A design staff understand is more secure in practice than a complex one they work around. Priya sees this in the troubleshooting cases later in the placement: when a control is confusing, teams are tempted to relax it rather than understand it. A design with a few clear boundaries, each with an obvious owner, lets staff predict what a change will affect. Kwame's rule of thumb is that anyone on the platform team should be able to explain a client's design in two minutes.
8.6 Architecture records
Each client has a one-page architecture record with layers and boundaries. The record lists the client's components, the boundaries between them, the controls at each boundary and any known gaps, such as the missing network policy between booking and reports. It fits on one page so that it is read. Priya updates Riverside Dental's record after her worked example, adding the gap with an owner, and links the record from the client's diagram so the two stay together. Kwame reads the record before approving any change that touches one of its boundaries.
Architecture and clients
Small clients often assume that being hosted means being protected. The architecture record lets Cobalt show clients which layers it manages and which remain theirs, such as choosing strong passwords for their own staff accounts on the booking system.
Reviewing the design
Kwame reviews each architecture record with the client once a year, checking whether new services added boundaries.
Worked example
Priya draws Riverside Dental's architecture with four boundaries: internet to proxy, proxy to cluster, cluster to database, cluster to monitoring service. For each she lists the controls present and one that is missing: no network policy between the booking and reports workloads.
Synthetic case. Architecture is synthetic.
Errors and limits
Layers help only if each is maintained; an unmonitored control can fail silently.
Exercises
- EX022 — Defence in depth. Give four layers protecting a client site. Rubric: 3 = network, TLS, admission, service accounts, logs; 2 = three; 1 = two; 0 = none.
- EX023 — Boundary definition. What makes a point in the system a trust boundary? Rubric: 3 = data moves between different trust levels; 2 = partial; 1 = vague; 0 = none.
- EX024 — Missing control. Which control was missing at Riverside Dental? Rubric: 3 = network policy between booking and reports; 2 = partial; 1 = vague; 0 = none.
Synthesis
Put controls at each boundary and keep the design simple enough to maintain.
Continue studying — chapter 08 of 30
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →