Microservices Security
1. Zero-Trust Between Services: mTLS
In a traditional network, security is like a castle with a moat: hard on the outside, soft on the inside. Zero-Trust assumes the network is already compromised. Every service must verify the identity of any other service trying to talk to it.
Mutual TLS (mTLS) is the gold standard for this. Unlike standard TLS (where only the client verifies the server), mTLS requires both sides to present and verify cryptographic certificates.
-
How it works: 1. Service A calls Service B.
2. Service B presents its certificate to Service A (proving its identity).
3. Service A presents its certificate to Service B (proving its identity).
4. Once verified, an encrypted tunnel is established.
-
Implementation: Doing this manually at the application code level is a nightmare. Instead, organizations use a Service Mesh (like Istio, Linkerd, or Consul). Sidecar proxies handle the certificate rotation, handshakes, and encryption automatically without the application ever knowing.
2. OAuth2/OIDC in a Microservices Context
While mTLS ensures Service A is allowed to talk to Service B, it doesn’t tell you who the user is. That’s where OAuth2 and OpenID Connect (OIDC) come in.
-
The Problem: Passing a user’s raw credentials (username/password) between internal microservices is a massive security risk.
-
The Solution: The Token Propagation pattern.
-
The user authenticates at the edge via OIDC and receives a JSON Web Token (JWT).
-
The API Gateway validates this token.
-
As the request moves deeper into the microservices chain (Service A $\rightarrow$ Service B $\rightarrow$ Service C), the JWT is passed along in the HTTP Authorization header.
-
-
Contextual Authorization: Services can decode the JWT to read user claims (e.g.,
user_id,roles: ["admin"]) to make fine-grained access control decisions (RBAC/ABAC).
3. API Security at the Gateway Layer
The API Gateway is your frontline defense. It acts as the reverse proxy that shields your internal microservices from the public internet.
Key security responsibilities handled at the gateway include:
-
TLS Termination: Handling the public-facing HTTPS certificates.
-
Authentication & Token Validation: Validating incoming OAuth2/OIDC tokens (checking signatures, expiration, and scopes) before forwarding the request inward.
-
Rate Limiting & Throttling: Preventing DDoS attacks and brute-force attempts by limiting requests per IP or per API key.
-
IP Whitelisting/Blacklisting & WAF: Blocking malicious payloads (SQL injection, XSS) using a Web Application Firewall.
The Separation of Concerns: The Gateway handles north-south traffic (internet to cluster), while the Service Mesh/mTLS handles east-west traffic (service to service).
4. Secrets Management
Microservices need access to sensitive data: database passwords, API keys for third-party services, and private certificates. Hardcoding these in source code or environment variables is a major vulnerability.
A dedicated Secrets Manager (like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault) solves this via:
-
Centralization & Encryption: Secrets are encrypted at rest and in transit, stored in a single secure plane.
-
Dynamic Secrets: Instead of static, forever-valid passwords, advanced managers can generate on-the-fly database credentials that expire after an hour.
-
Automated Rotation: Automatically changing API keys and passwords on a schedule without manual intervention.
-
Strict Access Control: Microservices use their machine identity (e.g., Kubernetes Service Accounts) to authenticate with the Secrets Manager and retrieve only the specific keys they need.
How It All Fits Together
| Security Layer | Focus Area | Primary Technology |
| API Gateway | Perimeter Security (North-South) | Kong, Apigee, Envoy, AWS API Gateway |
| OAuth2 / OIDC | User Identity & Authorization | Okta, Keycloak, Auth0, Ping Identity |
| mTLS / Service Mesh | Service Identity & Transport (East-West) | Istio, Linkerd, Consul |
| Secrets Management | Data Protection & Credentials | HashiCorp Vault, AWS Secrets Manager |