Trust Boundaries in a Payment Microservice Split
Northwind Payments processes about 4 million card transactions a day on a twelve-year-old Java monolith. Over eight months the platform team extracted 38 services onto one shared Kubernetes cluster. Every service runs in the same namespace, pulls a single shared database credential from a ConfigMap, and calls its neighbours with static API keys baked into container images. The QSA's preliminary cardholder data environment scope now covers 22 of the 38 services, because all of them can reach the card database over a flat pod network. The platform lead proposes a two-week fix: Kubernetes NetworkPolicies that allow only the six services that genuinely query the card database to reach its port. The p95 end-to-end latency budget is 120 ms, and a nightly four-hour settlement change freeze limits when anything risky can ship. There is no service mesh, no mTLS, and the platform team has never run a private PKI. The QSA re-scopes in 30 days.
1. Assess whether NetworkPolicies alone satisfy the intent of the QSA's segmentation requirement. What do they deliver, and what do they not?
Read the worked answer
They are necessary, they are not sufficient, and you should not let the QSA believe otherwise.
What they give you:
- L3/L4 allowlisting between pods, enforced by the CNI plugin - verify it actually enforces (Calico, Cilium, Antrea do; plain flannel does not) before anyone promises anything.
- A default-deny baseline plus explicit per-flow rules that can be reviewed and version-controlled.
- Reduced reachability, which is the mechanism segmentation is supposed to provide.
What they do not give you:
- Caller identity. Policies select pods by label. Any workload that can be scheduled with the right labels, or that compromises an already-allowed pod, inherits the reach. There is no proof the request came from the real settlement service.
- Credential separation. All six allowed services still share one database credential, so from an access-rights perspective the CDE is still 22 services. Policies do not reduce the set of principals that can read card data.
- Confidentiality in transit. Pod-to-pod traffic is still plaintext and observable on the node and in any log pipeline.
- Detection. Deny events are only a control if they are logged somewhere an analyst looks and alerts on anomalies.
Judgement: ship the policies inside the two weeks as an interim control, document them as compensating rather than scope-reducing, and tell the QSA the identity work follows. Scope reduction comes from default-deny plus per-workload credentials plus authenticated, encrypted service identity. Claiming de-scoping on policies alone is the assertion that fails the first time the QSA tests what a compromised pod can reach.
2. Design the service identity control that closes the gap, including how you sequence it around the 120 ms latency budget and a four-hour nightly freeze.
Read the worked answer
Target state: workload identity issued by the platform, not by humans. A SPIFFE ID (or the mesh's own identity) per service, short-lived certificates rotated hourly, mTLS mandatory. Database access through dynamic per-service credentials with a distinct database role per service, so the card database can distinguish settlement from reporting.
Why not TLS bolted onto the existing API keys: rotation without an automated issuer is exactly the failure you already have - keys in images, never rotated, copied into CI logs. Static keys with TLS authenticate the key, not the workload.
Latency. Sidecar proxies typically add 1–3 ms p95 per hop. Against a 120 ms budget that is usually affordable, but it must be measured on the settlement path at peak, not on a test cluster. If it does not fit, use an ambient/eBPF dataplane or node-level mTLS to cut per-hop cost. Do not accept a design nobody has benchmarked against the real traffic.
Sequencing:
- Weeks 1–2: default-deny policies, separate namespace and node pool for the six CDE services, deny logging into the SIEM.
- Weeks 3–6: stand up the issuer; run mTLS in permissive mode, then enforce service by service, least-coupled first.
- Weeks 6–10: per-service database roles, then revoke the shared credential - revocation is the proof of cutover.
- Weeks 10–14: image signing and admission control so unlabelled or unsigned pods cannot join the CDE namespace.
Capability is the real risk. Two engineers learning PKI during a settlement freeze is how outages happen. Buy a short engagement or use a managed CA, but own the runbook and the rollback before the QSA returns.
3. Beyond network controls, what architecture changes would you drive to shrink the CDE from 22 services to a defensible minimum, and how do you evidence it?
Read the worked answer
Reduce scope structurally, not just by firewall rule.
- Tokenize the PAN. If the settlement path emits a surrogate, downstream services never touch card data and drop out of scope by construction. It is an application change with a long lead time, so start it now and let it land after this re-scope rather than promising it as a 30-day item.
- Define a minimal CDE: the six services that genuinely read card data plus their datastore, in a dedicated cluster or node pool with taints, its own policy set, its own administrative access path, and a separate log destination so cluster admins cannot edit CDE audit records.
- Break-glass administration only. No standing cluster-admin for platform engineers inside the CDE; time-bound elevation with session recording.
- Split the data store. A dedicated database instance for the six services makes the boundary physical rather than nominal, and removes the shared credential question entirely.
Evidence. Produce a data-flow diagram - source, destination, port, credential, encryption, data classification - and walk the QSA through it. Then demonstrate the control: attempt the connection from a non-CDE pod and show the deny, with the test output and timestamp. Scope is a negotiation backed by artefacts; a diagram plus a validated test is what actually moves 22 services down to six.
What not to do: relabel the 22 services as in scope but low risk and hope. Either the data is there or it is not, and the 30-day re-scope will find it.