Security
Istio provides a security layer for service-to-service communication. It gives each workload a cryptographic identity and can encrypt and authorize traffic between workloads without changes to application code.
What it Gives You
- Mutual TLS (mTLS) - encrypt traffic between workloads and have both sides verify each other’s identity.
- Workload identity - every workload receives a SPIFFE-based identity derived from its Kubernetes service account, issued and rotated automatically.
- Authorization policy - control which workloads are allowed to call which other workloads, down to specific paths and methods.
- Request authentication - validate end-user credentials such as JWTs on incoming requests.
How it Works
istiod acts as a certificate authority, issuing short-lived certificates to each proxy. The proxies use these certificates to establish mTLS connections automatically.
| Resource | Purpose |
|---|---|
PeerAuthentication | Configures mTLS mode (PERMISSIVE or STRICT) for workloads |
AuthorizationPolicy | Allows or denies traffic between workloads based on identity, namespace, path, and more |
RequestAuthentication | Validates JWTs for end-user authentication |
mTLS Modes
- PERMISSIVE - workloads accept both mTLS and plaintext traffic. This is the default and is useful while onboarding services into the mesh.
- STRICT - workloads accept only mTLS traffic. Plaintext calls are rejected. Use this once all callers are in the mesh.
Tip
Start in PERMISSIVE mode while migrating services into the mesh, then move to STRICT once you have confirmed every caller is meshed. You will enable and verify STRICT mTLS in Lab 4
.
When to Use It
- Meeting zero-trust or encryption-in-transit requirements
- Restricting which services can talk to sensitive workloads
- Providing identity-based access control without managing per-service credentials in code