Trust models
| Model | Security | Ops |
|---|---|---|
| Flat network | Anyone in VPC calls anyone | Easy, unacceptable at scale |
| Shared secret | Bearer token all services share | Rotation nightmare |
| Per-service credentials | OAuth client credentials | Better |
| mTLS + identity | Cryptographic workload ID | Best at scale |
Microservices → Service Mesh — operational mTLS. Interview: know why, not every Istio YAML key.
SPIFFE / SPIRE (awareness)
Workload gets SVID (cert with SPIFFE ID). Mesh uses this for mTLS peer verification.
Network policies (K8s)
Default deny east-west; allow only required paths:
payments → ledger:443
payments → postgres:5432
deny all else
Defense when app bug exposes port — limits lateral movement.
Zero-trust (engineer summary)
No "inside firewall = trusted." Authenticate every call, authorize every action, encrypt in transit.
Microservices Deep Cuts expands; Networking covers TLS mechanics.
Metadata service SSRF
Cloud 169.254.169.254 — why SSRF in any service is platform-critical (API Security topic).
Distributed systems interview
"50 microservices — how authenticate?" — mTLS mesh or central identity + client credentials; network policies; no static keys in git.
Cross-reference: Distributed Systems — correctness separate from security; both required.
Further Reading
- SPIFFE — Workload identity overviewReference15m
- Kubernetes — Network Policies (pod-level firewall)Reference20m
Hands-On Tasks (Optional)
Security design drills — threat modeling, auth flows, and incident playbooks. Assumes Networking (TLS) fundamentals.
- Design east-west auth for 20 services15m
Compare: shared API key (anti-pattern), mTLS mesh, OAuth client credentials per service. Pick one and justify rotation and blast radius.