Secure Service Communication: CNPA practice questions

Secure service communication means that when one workload calls another, both sides can be sure who they are talking to, the traffic cannot be read or altered in transit, and only permitted calls get through. In a cluster where Pods come and go and IP addresses are reused, network location is a weak identity, so cloud-native platforms move toward cryptographic workload identity and mutual TLS, in which both client and server present certificates.

SPIFFE is a set of open-source standards for that identity. A SPIFFE ID is a URI of the form spiffe://trust-domain/workload-identifier, for example spiffe://acme.com/billing/payments. The trust domain corresponds to the trust root of a system, and SPIFFE advises keeping workloads in different locations or with different security practices, such as staging and production, in distinct trust domains. A workload proves its identity with an SVID, a SPIFFE Verifiable Identity Document, which is either an X.509 certificate or a JWT. Because tokens can be replayed if intercepted, SPIFFE recommends X.509-SVIDs wherever possible. Through the Workload API a workload receives its identity, a private key and a short-lived certificate, plus a trust bundle for verifying other workloads. SPIRE is a production-ready implementation of the SPIFFE APIs that attests nodes and workloads before issuing SVIDs.

Service meshes apply the same ideas without changing application code. Istio gives every workload a strong identity, which on Kubernetes is its service account, and its control plane, istiod, acts as the certificate authority that signs certificates for the proxies and repeats the process periodically for rotation. Proxies then establish mutual TLS between workloads and act as policy enforcement points. A PeerAuthentication policy sets the mode: PERMISSIVE accepts both mutual TLS and plain text, which helps during a migration while some clients still lack a sidecar, and STRICT accepts only mutual TLS. Istio's documentation recommends switching to STRICT once workloads are migrated. Authorization policies then control which identities may reach which workloads.

Kubernetes NetworkPolicy works at a different layer. It controls traffic at the IP address or port level, layer 3 or 4, and is only enforced if the cluster's network plugin supports it. By default Pods are non-isolated and all connections are allowed; once a policy selects a Pod for a direction, only the traffic that policies allow gets through. Network policies and mTLS complement each other: one limits which connections can be made, the other proves identity and encrypts what flows over them.

The Platforms White Paper lists identity and secret services, with SPIFFE/SPIRE and cert-manager among the examples, as a platform capability, so application teams do not have to manage certificates themselves.

Misconceptions include treating TLS at the ingress as enough for traffic inside the cluster, believing NetworkPolicies encrypt traffic, and leaving a mesh in permissive mode for good.

At associate level, expect questions on what mTLS adds over one-way TLS, how SPIFFE IDs and SVIDs work, the difference between permissive and strict modes, and when to use network policies versus mesh authorization.