Chapter 16 — Security architecture
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Account structure"]
N2["16.2 Organisation guardrails"]
N3["16.3 Cluster design"]
N4["16.4 Trust boundaries"]
N5["16.5 Zero trust"]
N6["16.6 Documentation"]
N7["16.7 Review"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Account structure"]
N2["16.2 Organisation guardrails"]
N3["16.3 Cluster design"]
N4["16.4 Trust boundaries"]
N5["16.5 Zero trust"]
N6["16.6 Documentation"]
N7["16.7 Review"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 Account structure]
|
v
[16.2 Organisation guardrails]
|
v
[16.3 Cluster design]
|
v
[16.4 Trust boundaries]
|
v
[16.5 Zero trust]
|
v
[16.6 Documentation]
|
v
[16.7 Review]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) design a layered architecture for StudyHub; (2) separate accounts and environments; (3) place trust boundaries; (4) use guardrails at organisation level.
16.1 Account structure
Westmere uses separate cloud accounts for production, test, research sandboxes, shared tooling and logs. Accounts are strong boundaries: a mistake in a sandbox cannot change production resources.
The research sandbox shows why: researchers experiment freely there, and a mistake such as a public bucket stays inside that account. If the sandbox shared an account with StudyHub production, the same mistake could expose student services. Separate accounts also make it simpler to give each team full control of its own space without access to others.
16.2 Organisation guardrails
Policies at the organisation level block public storage, restrict regions to the home region and prevent disabling audit logs. Guardrails apply to every account, including ones created in the future.
Guardrails act before a mistake happens, while checkers find mistakes afterwards. The researcher's public bucket in the evidence chapter was blocked by a guardrail, not found later by a scan. Applying guardrails to future accounts closes the gap that created the opening case, where a new account missed a setting.
16.3 Cluster design
Production and test clusters are separate. Within production, namespaces separate services, with default-deny network policies and Restricted pod security.
Separate clusters mean a test deployment cannot accidentally affect production pods. Within production, default-deny network policies stop one compromised service from reaching others, and Restricted pod security limits what any single container can do. Each namespace belongs to one team, which keeps ownership clear. Test clusters may use relaxed settings for debugging, but they never hold real student data, and their credentials cannot reach production resources. Samuel's checker runs against both clusters, with the production checks treated as stricter.
16.4 Trust boundaries
Internet to load balancer; cluster to managed database; build system to registry; registry to cluster; accounts to log account. Each boundary has authentication and logging.
The build-to-registry boundary was where the opening case started: the registry trusted anonymous requests from anywhere. Now the build system authenticates with its own identity, and pulls by the cluster use the cluster's identity. Every push and pull is logged in the central log account, so the same question asked again would have an answer.
16.5 Zero trust
Following NIST SP 800-207, services authenticate each other and every request is authorised, rather than trusting anything inside the network.
In StudyHub, records-api no longer accepts any request simply because it comes from inside the cluster. Each calling service presents its own identity, and records-api checks that the caller is allowed the specific operation. A compromised pod elsewhere in the cluster therefore cannot query student records just by reaching the service on the network. Network policies still limit which pods can reach records-api, so the two layers support each other.
16.6 Documentation
An architecture diagram and decision records explain each choice.
Decision records state the problem, the options considered, the choice and its reasons. When a new team member asked why the sandbox had its own registry, the record answered the question in a few minutes. Without it, the reason might have been forgotten and the registries merged again for convenience. The diagram shows accounts, clusters, trust boundaries and the main flows on one page, and links to the detailed system model. Decision records are short, usually under a page, and are numbered so later records can refer to earlier ones. Superseded decisions stay in the repository with a note pointing to their replacement.
16.7 Review
Architecture changes are reviewed by the cloud team and a security reviewer.
The security reviewer looks particularly at new trust boundaries and changes to guardrails. A proposal to let the research sandbox pull from the production registry was rejected in review with a reference to the decision record, and the team found another way to share the base image the researchers needed. Reviews are recorded in the pull request, so the reasoning stays with the change. Small changes that do not touch boundaries or guardrails are reviewed by the cloud team alone, which keeps the security reviewer's time for the decisions that need it.
Account creation
New accounts are created only through an automated process that applies guardrails, logging and baseline roles from the start. Manual account creation is disabled. This means that a research group requesting a sandbox gets one that already blocks public storage and sends logs centrally, without anyone having to remember. Samuel tests the process with a synthetic request and confirms the new account passes all baseline checks on its first day.
Worked example
Applying the account structure reveals that the research sandbox shared the production registry, which is how a research image could be pushed alongside StudyHub images. A separate sandbox registry is created, and production accepts images only from its own registry.
Synthetic case. Architecture is synthetic.
Errors and limits
Guardrails can block legitimate needs; provide a documented exception route.
Exercises
- EX046 — Account benefit. Why use separate accounts? Rubric: 3 = strong boundary for mistakes; 2 = partial; 1 = vague; 0 = none.
- EX047 — Guardrails. Name two organisation guardrails. Rubric: 3 = block public storage, restrict regions, keep audit logs; 2 = one; 1 = vague; 0 = none.
- EX048 — Shared registry. What was found and fixed? Rubric: 3 = sandbox shared prod registry; separated; 2 = partial; 1 = vague; 0 = none.
Synthesis
Use accounts, guardrails and boundaries as layered architecture.
Continue studying — chapter 16 of 40
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →