Infrastructure-level authorization enforces access through shared platform components rather than each service’s application logic. Service meshes and API gateways check identity and permissions before requests reach the service, creating centralized policy enforcement and reducing inconsistent security practices. section 16.3
Common infrastructure enforcement patterns include:
- Use a service mesh with mutual TLS (mTLS) to verify service identities and secure internal, service-to-service traffic through sidecar proxies. section 16.3 section 16.5
- Use an API gateway as an external entry point to authenticate requests, validate tokens, and enforce access control before forwarding traffic. section 16.3 section 16.5
- Combine infrastructure authorization with application-level authorization when rules depend on business context or service-owned data. section 16.3 section 16.5
A protected service request
A service deployed with a sidecar proxy receives a request through the proxy. The sidecar evaluates configured authorization rules and forwards the request only when it is allowed. The service can still apply finer-grained business rules that require application data. section 16.3
Figure 16.9 The anatomy of a pod. The two apps—the sidecar app, which takes care of authorization, and the service—are always deployed together and can be scaled only together. The sidecar app intercepts all requests and decides whether to forward the request to the service based on the configured authorization rules.
Shows how a sidecar and service are deployed together, with the sidecar intercepting requests and deciding whether to forward them. section 16.3
