Chapter 8 — Security architecture basics
Lesson map
Lesson 08 published. Map, example, EX015.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Boundaries and termination"]
N2["8.2 Annotated diagrams"]
N3["8.3 Agility features"]
N4["8.5 Practical activity"]
N5["8.7 Review checklist"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX015"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Boundaries and termination"]
N2["8.2 Annotated diagrams"]
N3["8.3 Agility features"]
N4["8.5 Practical activity"]
N5["8.7 Review checklist"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX015"]
[Learning outcomes]
|
v
[8.1 Boundaries and termination]
|
v
[8.2 Annotated diagrams]
|
v
[8.3 Agility features]
|
v
[8.5 Practical activity]
|
v
[8.7 Review checklist]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX015]
Learning outcomes
You will (1) draw service diagrams with trust boundaries; (2) annotate flows with algorithms and data lifetimes; (3) explain TLS termination points and their consequences; and (4) describe crypto-agility features an implementer can build.
8.1 Boundaries and termination
Traffic crosses boundaries — internet to edge, edge to service mesh, service to database, office to cloud. TLS is often terminated and re-established at each hop: CDN, load balancer, ingress, sidecar. Each termination is a separate negotiation with its own algorithm choice; a hybrid group at the CDN says nothing about the CDN-to-origin hop.
KLS counts five TLS terminations on the customer path alone, and each has a different owner. The diagram must therefore show every termination with its controller, because each owner configures and changes its own hop on its own schedule.
8.2 Annotated diagrams
Annotate each flow with protocol, key exchange, authentication, data lifetime and who controls each end. The annotated diagram is the implementer's map: flows with long-lived data, classical key exchange and an untrusted path are the first to change.
KLS uses a single line per flow: CDN→origin LB | TLS 1.3 | ECDHE X25519 | ECDSA P-256 | 10 y | KLS+CDN. Listing the data lifetime on the line is what makes the CDN-to-origin hop stand out: same protocol as the browser hop, but classical, and carrying the same ten-year shipment data across networks KLS does not control.
8.3 Agility features
Implementers build agility by: configuring algorithms in one place (central TLS profiles, ingress annotations, crypto policies); keeping algorithm identifiers in stored data; using libraries that support several algorithms; leaving room in fields and buffers for larger keys; and testing every configured algorithm in CI. NIST's CSWP 39 discusses these considerations.
At KLS each feature has a test. The central profile is rendered in CI and compared with the approved one. Stored signatures carry an algorithm identifier, so verifiers can accept two algorithms during transition. Database columns for keys are sized for ML-DSA-87. A pipeline job attempts a handshake with each configured group against staging, so a group listed but unsupported fails before deployment, not after.
8.4 Worked example
KLS's customer path: browser → CDN (hybrid) → origin load balancer (classical) → ingress (classical) → API pods (plaintext inside mesh with mTLS sidecars, ECDHE). The internet hop is protected; the CDN-to-origin hop crosses the provider's network and the internet and carries ten-year data. Priority: enable hybrid on the origin load balancer and ingress; then evaluate the mesh.
The plan places the first changes where KLS controls both ends and the data is long-lived. The origin load balancer and ingress are KLS configuration; the CDN's origin settings are a provider option KLS can enable. The mesh is left for evaluation because its hops stay inside one provider's network and its sidecars are upgraded on the platform release schedule.
8.5 Practical activity
Draw and annotate the path for KLS's partner SFTP and office VPN flows; mark termination points.
For partner SFTP the path is short: partner client → internet → KLS bastion → SFTP host, with SSH terminating once, at the bastion or the host depending on the design. For the office VPN, show the office appliance, the internet, the cloud VPN gateway and the internal hop to services, noting that IPsec terminates at the gateway and traffic continues over the mesh. Give every hop the same five annotations as the diagram rule above. Mark any hop where you could not find the algorithm as unknown.
8.6 Common errors and limits
- Judging the whole path by the first hop.
- Hard-coding cipher suites in many places.
- Diagrams without data lifetimes.
KLS made all three. The early report "customer path is hybrid" judged the path by the browser-to-CDN hop. Cipher lists were hard-coded in the ingress, two load balancers and a sidecar template, so changing them meant four reviews and one forgotten location. And the first diagrams showed algorithms but not lifetimes, which made telemetry and shipment flows look equally urgent. The limit of diagrams is that they are drawn by hand; the traces in Chapter 12 turn them into data.
8.7 Review checklist
When reviewing a new service design, ask: which hops terminate TLS, and who configures each; which groups and signature algorithms each hop offers and prefers; where algorithm choices are configured; which stored data carries algorithm identifiers; and whether any field, buffer or message limit assumes classical sizes. Five questions asked at design time prevent most of the rework that later inventories uncover.
KLS adds the five questions to its design-review template. In the first quarter they flagged a new reporting service storing signatures in a 256-byte column and a new queue whose client library pinned classical groups.
Exercises
- EX015 — Termination. Explain why a hybrid CDN edge does not protect the CDN-to-origin hop. Rubric: 3 = separate TLS sessions and negotiation.
- EX016 — Agility feature. Describe one agility feature you could add to KLS's ingress configuration. Rubric: 3 = central profile or annotation with test.
Synthesis
Annotated diagrams reveal each termination point as a separate negotiation; agility features let implementers change all of them from one place.
Continue studying — chapter 08 of 30
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →