Part 6 · 2 chapters · ~12 min

Service-to-Service Authentication

Why static API keys between services fail, workload identity from the platform, SPIFFE and SPIRE, mTLS with authorisation by caller identity, OIDC federation to cloud IAM, client credentials and token exchange for user context, and zero-trust networking.

13

Workload identity and mTLS

WORKLOAD IDENTITY
services prove who they are with platform-issued, short-lived credentials
mTLSplatformk8s service account, cloud IAMSPIRE / mesh CAissues SVIDstransfers servicespiffe://bank/ns/pay/sa/transfersledger servicechecks caller identitycloud APIsIAM role via OIDC federation
swipe the figure sideways, or tap expand for full screen
1/5
no shared secrets
Service-to-service calls should not use static API keys copied into config. The platform already knows what each workload is; use that as its identity.
identity from the platform, not static keysstatic keys leak and never rotate
14

Tokens between services

code
# a service acting as itself: client credentials (cache the token until shortly before expiry)
POST /oauth/token  grant_type=client_credentials&client_id=transfers&scope=ledger.post   (client auth via mTLS or private_key_jwt)

# a service acting for a user: token exchange to a narrower, audience-bound token
POST /oauth/token  grant_type=urn:ietf:params:oauth:grant-type:token-exchange
  &subject_token=<user access token>&audience=ledger-api&scope=ledger.read

Zero trust means no request is trusted because of where it comes from (inside the VPC, inside the cluster). Every call carries an identity that is authenticated and authorised, the network is assumed hostile, and access is the minimum needed.