Chapter 21 — Quantum and post-quantum security: service integration
Lesson map
Lesson 21 published. Map, example, EX041.
flowchart TD
N0["Learning outcomes"]
N1["21.1 Layer by layer"]
N2["21.2 Managed services"]
N3["21.3 Partners and customers"]
N4["21.4 Compatibility during transition"]
N5["21.6 Practical activity"]
N6["21.7 Integration testing"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX041"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 Layer by layer"]
N2["21.2 Managed services"]
N3["21.3 Partners and customers"]
N4["21.4 Compatibility during transition"]
N5["21.6 Practical activity"]
N6["21.7 Integration testing"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX041"]
[Learning outcomes]
|
v
[21.1 Layer by layer]
|
v
[21.2 Managed services]
|
v
[21.3 Partners and customers]
|
v
[21.4 Compatibility during transition]
|
v
[21.6 Practical activity]
|
v
[21.7 Integration testing]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX041]
Learning outcomes
You will (1) integrate post-quantum settings across CDN, load balancer, ingress, mesh and application layers; (2) coordinate with managed-service providers; (3) handle partner and customer integrations; and (4) maintain compatibility during transition.
21.1 Layer by layer
Integration means every hop agrees. At the CDN, enable hybrid key exchange to clients and to origin where the provider supports it. At the origin load balancer and ingress, apply the central profile. In the service mesh, upgrade sidecar proxies and control-plane certificates; mesh mTLS is internal but may cross shared networks between availability zones. In applications, upgrade SDKs that make outbound calls to partners and cloud APIs.
For KLS the order of hops in the customer API flow fixes the order of work: CDN settings first, because the provider controls them and needs lead time; then KLS's own load balancer and ingress; then the mesh on the platform release cycle; and the SDKs last, because customers adopt them at their own pace.
21.2 Managed services
Managed databases, queues and object storage negotiate TLS with libraries the provider controls. Ask providers which groups their endpoints offer, whether hybrid is available, and how to require it. Record answers as vendor evidence and verify from client-side logs where possible. Some providers expose post-quantum options per endpoint or region; others publish roadmaps only.
KLS's questions to providers are written the same way each time: which groups the endpoint offers today, whether a hybrid group is available and in which regions, whether KLS can require it, and how KLS can verify it. Answers are dated and stored as vendor evidence; a roadmap slide is recorded as "planned", never as supported.
21.3 Partners and customers
Partners integrate through SFTP, APIs and VPNs. Publish a compatibility notice: what KLS now offers, what KLS will require and when, and a test endpoint. Keep classical fallback during a published transition window; set an end date aligned with policy and contracts, and track partner adoption.
KLS tracks partner adoption from its own sshd logs, which show the KEX algorithm each partner's client negotiates. Of the six client types seen, two were classical-only at the start of the window. Those partners receive a direct reminder at the six- and nine-month marks, with the test endpoint and the end date.
21.4 Compatibility during transition
Offer hybrid and classical, prefer hybrid, monitor fallback, and remove classical only when fallback share is below an agreed threshold for an agreed period and exceptions are documented. For certificates, run dual chains or dual endpoints only where products support them cleanly; otherwise keep classical certificates until relying parties can verify ML-DSA.
KLS's threshold for removing classical groups from a listener is a fallback share below 1 % for 30 consecutive days, with every remaining client listed as an exception with owner and expiry. Until then, the profile offers and prefers the hybrid while still accepting X25519, and the dashboard shows the fallback share beside the hybrid share.
21.5 Worked example
KLS integration plan for the customer API: CDN hybrid to clients (done) and to origin (provider supports it from Q1; enable and verify in origin logs); origin LB and ingress kls-modern profile; mesh sidecars upgraded in the next platform release; outbound SDK calls to the payment provider remain classical until the provider supports hybrid (vendor ticket). Partner notice published with a staging endpoint and a twelve-month window before classical-only partners must upgrade.
The plan lists each hop with an owner and the evidence that will close it, so status is counted by hop, not by effort. Two hops, the CDN-to-origin link and the payment provider calls, depend on third parties; both are tracked as dated requests, and the flow is reported as partly migrated until both close.
21.6 Practical activity
Write an integration checklist for one KLS flow covering every hop, the owner, evidence of completion and the external dependencies.
For the customer API, list the client → CDN, CDN → origin load balancer, load balancer → ingress, ingress → pods and pod → payment-provider hops. For each give the owner, the setting or upgrade needed, the evidence that proves it (a log field, a synthetic test result, a written provider statement) and the external dependency with its contact. Add the end-to-end test as the final line. A hop without evidence stays open, however confident the owner is.
21.7 Integration testing
Integration tests should exercise the whole path, not each hop alone: a synthetic client in each customer region calls the API through the CDN and records the negotiated group at the edge and, via origin logs, at the origin. Run the test after every change to any hop. When the test fails at one hop, the per-hop evidence tells you where to look. This end-to-end check is what lets the team claim that a flow, rather than a component, is migrated.
21.8 Common errors and limits
- Migrating hops independently with no end-to-end check.
- Removing classical support before partners are ready.
- Treating provider roadmaps as delivered features.
KLS hit the first error when the ingress and load balancer were migrated in separate sprints and nobody tested the path; the origin hop was still classical because the CDN's origin option had not been enabled. The second was avoided by the partner window; a test removal on the staging SFTP host showed two partner client types failing at once. The third is common: a provider slide promising hybrid "in Q1" was cited as done in a status report and had to be corrected.
Exercises
- EX041 — Hop checklist. List every hop for KLS's customer API flow and the evidence that each is migrated. Rubric: 3 = all hops with concrete evidence.
- EX042 — Partner notice. Draft a five-sentence partner notice for SFTP hybrid key exchange. Rubric: 3 = what, when, test endpoint, fallback window, contact.
Synthesis
Service integration aligns every hop, documents provider and partner dependencies and keeps compatibility through a measured transition window with end-to-end tests.
Continue studying — chapter 21 of 30
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →