Identity-aware policy: authentication is evidence, authorization is a decision

SPIFFE represents a workload identity through a SPIFFE ID and a verifiable identity document. For X.509-SVID authentication, validation includes the appropriate trust domain and certificate-path requirements, the identity encoded in the certificate, and the TLS peer's possession of its private key through the handshake. The Workload API supplies identity material and trust information according to the implementation's attestation and entitlement rules. Reaching a local API socket is not permission to arbitrarily claim every identity; caller identification and issued-identity authorization remain essential parts of the provider.

A workload identity can represent a service account or another configured security principal rather than a unique application user. Several replicas may legitimately share the same principal. Mutual TLS authenticates channel peers and protects transport; it does not automatically validate end-user permissions or prove application readiness. Credential rotation also requires clients to receive and use fresh identity material and trust bundles. A cached credential must still meet its validity and trust requirements when the chosen authentication mechanism evaluates it.

A Layer 4 policy can use authenticated peer identity and transport attributes without understanding an HTTP method or path. A Layer 7 policy requires an HTTP-aware enforcement point, such as a sidecar HTTP filter or an appropriate waypoint in the chosen architecture. In the documented Istio ambient variant, source type and waypoint enrollment affect whether traffic reaches that Layer 7 component. Define policy coverage for direct pod access, service access, gateways, out-of-mesh clients, and excluded ports rather than assuming one label makes every path equivalent.

Headers containing a claimed user or certificate identity are not automatically trustworthy. An application must know which trusted component supplied them, how untrusted values were removed or replaced, and whether a bypass path can reach the application directly. Mesh authorization should also be tested independently from application authorization: a valid service principal might be allowed to call an API while still lacking permission for a particular account. Kubernetes readiness and health probes are operational signals, not substitutes for either permission check, even when they traverse authenticated transport.

Create explicit cases for an unknown trust domain, expired credential, valid but disallowed workload, wrong HTTP operation, and allowed mesh identity with denied application permission. Observe which component rejects each request and whether logs preserve the validated principal without exposing private keys. Check failure behavior when external authorization or credential delivery is unavailable. A permissive fallback and a fail-closed rule are different policies; document the configured choice instead of assuming every mesh responds identically. Successful requests alone cannot demonstrate that disallowed paths are blocked.

The probability lab illustrates a hypothetical workload mixture, not cryptographic validation. Reset, set p=0.25 and n=20, predict five policy-denied requests on average, then Play or Step. Separately Reset, set p=0.50 and n=20, predict ten, then Play or Step. The independent binomial model merely counts stipulated request labels; it does not evaluate credentials or authorization. Use it to distinguish aggregate denial-rate telemetry from proof that each required negative test is enforced. A low denial fraction may mean good legitimate traffic, missing coverage, or incorrect acceptance.