In a zero-trust environment, how do you establish trusted identity for service-to-service calls without sharing long-lived secrets between services?
technical-conceptual · Mid level · cloud-devops-security
What the interviewer is really asking
Tests whether the candidate can extend zero trust to workload (machine) identity using cryptographic, short-lived, attested identities and mTLS, rather than passing API keys around.
What to say
- Frame the goal: zero trust applies to workloads too, so each service needs a verifiable cryptographic identity rather than a shared API key, because a leaked static key authenticates any caller who holds it.
- Describe the mechanism: a framework like SPIFFE/SPIRE attests each workload's properties and issues it a short-lived SVID (an X.509 cert or JWT carrying a structured ID), and services establish mTLS where each side validates the other's identity against a trust bundle and authorization policy.
- Note the payoff and where authorization lives: identities are short-lived and auto-rotated so there's no secret to steal long-term, and you still enforce which identity may call which service via policy, not just whether the cert is valid.
What to avoid
- Defaulting to shared static API keys or a single service account everyone reuses, which makes a leak indistinguishable from legitimate traffic.
- Treating mTLS as merely encryption and forgetting that the point is mutual identity verification plus authorization.
- Assuming network position or a private VPC substitutes for verifying the calling workload's identity.
Example answers
Strong: Each workload gets its own cryptographic identity instead of a shared key. With SPIFFE/SPIRE the agent attests the workload and issues a short-lived SVID, and services talk over mTLS where both ends validate the peer's identity against the trust bundle. Because the certs are short-lived and rotated there's no durable secret to steal, and I still enforce which identity may call which service through authorization policy, not just a valid cert.
Weak: Each service gets an API key stored in the secrets manager and passes it in a header, and we rotate the keys periodically. They're all inside the VPC so traffic between them is trusted anyway.