Microservices Securing Services
Security in a microservices system is more complex than in a monolith. In a monolith, you secure one entry point. In microservices, requests travel between many services. Each hop is a potential target. A solid security strategy protects every layer — from the client all the way to the database.
The Security Surface in Microservices
ATTACK SURFACES
================
[Client] ---> [API Gateway] ---> [Order Service] ---> [Payment Service]
|
[Orders DB]
Attack points:
1. Client sends fake identity token
2. Attacker bypasses gateway and calls Order Service directly
3. Order Service calls Payment Service without authentication
4. Database access from an unauthorized service
5. Traffic intercepted between services (no encryption)
Each of these points needs specific protection.
Authentication with JWT
JWT stands for JSON Web Token. It is a compact, signed token that carries user identity information. When a user logs in, the Auth Service issues a JWT. The user sends this token with every subsequent request.
JWT FLOW
=========
1. User logs in with username + password
|
v
2. Auth Service verifies credentials
Issues JWT: eyJhbGciOiJSUzI1NiJ9... (signed string)
|
v
3. User stores JWT (in browser or mobile app)
|
v
4. Every request includes JWT in the header:
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...
|
v
5. API Gateway validates JWT signature
Extracts user_id, role, permissions
Passes request to the correct service
The JWT has three parts: a header (algorithm used), a payload (user data), and a signature (cryptographic proof it was not tampered with). A service validates the signature without calling the Auth Service — this makes token validation fast and stateless.
Authorization: What You Can Do
Authentication answers "who are you?" Authorization answers "what are you allowed to do?"
ROLE-BASED ACCESS CONTROL (RBAC) ================================== User role = "customer" - Can view own orders: YES - Can cancel own orders: YES - Can view all customers: NO - Can process refunds: NO User role = "support_agent" - Can view all customers: YES - Can process refunds: YES - Can delete accounts: NO User role = "admin" - Can delete accounts: YES - Can modify pricing: YES
Roles are embedded in the JWT. Each service checks the role before executing a sensitive action. The Order Service rejects a request to view another user's orders even if the JWT is valid, because the role does not permit it.
Service-to-Service Authentication
When the Order Service calls the Payment Service internally, the Payment Service must verify that the caller is legitimate — not a rogue process inside the network.
Mutual TLS (mTLS)
In regular HTTPS, only the server presents a certificate (proving "I am really payment-service.internal"). In Mutual TLS, both sides present certificates. The server proves its identity to the client, and the client proves its identity to the server.
mTLS HANDSHAKE =============== [Order Service] <-- "Here's my certificate. Who are you?" --> [Payment Service] [Order Service] --> "Here's my certificate" --> [Payment Service] Payment Service: "Certificate is valid. Order Service is trusted. Proceed." Order Service: "Certificate is valid. Payment Service is trusted. Proceed." If either certificate is invalid: connection refused.
Service meshes like Istio automate mTLS between all services without requiring each developer to implement it manually.
Service Tokens (API Keys)
Each service gets its own API key or service account token. When Service A calls Service B, it includes its service token. Service B checks that the token belongs to a trusted internal caller.
Secrets Management
Services need passwords, database credentials, API keys, and encryption keys. These must never be stored in code or environment variable files that get committed to version control.
WRONG: Hard-coded in code
db_password = "mypassword123" # Committed to Git. Everyone can see it.
WRONG: In a .env file committed to Git
DB_PASSWORD=mypassword123
RIGHT: Retrieved from a Secrets Manager at runtime
db_password = secrets_manager.get("prod/db/password")
Secrets Manager stores secrets encrypted.
Services fetch secrets at startup.
Secrets rotate without redeployment.
Popular secrets management tools include HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault.
Network Security
Encrypt All Traffic
All traffic between services travels over TLS (HTTPS). Even internal traffic. Even on a private network. Attackers who gain access to internal network traffic see only encrypted data.
Network Policies
In Kubernetes, Network Policies define which services can talk to which. The Analytics Service cannot call the Payment Service unless explicitly allowed. This limits the damage if any single service is compromised.
NETWORK POLICY EXAMPLE ======================= Payment Service accepts connections from: - Order Service (allowed) - Refund Service (allowed) - Analytics Service (BLOCKED) - Anything else (BLOCKED) Even if Analytics Service is compromised, it cannot reach Payment Service.
Input Validation and API Security
Every service validates its inputs before processing them. The API Gateway provides a first layer of validation. Each service adds its own checks for business rules.
- Validate data types and sizes — reject a name field containing 10,000 characters.
- Reject unexpected fields — ignore or refuse fields not in the API contract.
- Sanitize inputs that go into databases — prevent SQL injection.
- Rate limit per user at the gateway — prevent brute force attacks on login endpoints.
Security Audit Logging
Log every sensitive action — who did it, when, and what changed. These logs feed into a security monitoring system that detects unusual patterns.
AUDIT LOG EXAMPLE ================== 2025-03-14 11:42:01 | user_id=USR-99 | action=REFUND | order=ORD-1201 | amount=89.99 2025-03-14 11:42:05 | user_id=USR-99 | action=REFUND | order=ORD-1202 | amount=124.50 2025-03-14 11:42:07 | user_id=USR-99 | action=REFUND | order=ORD-1203 | amount=200.00 Security system detects: 3 refunds in 6 seconds by same user. Alert triggered.