Why security spans all services in Microservices - Design It to Understand It

Design: Microservices Security Architecture

Focus on security mechanisms that apply across all microservices, including authentication, authorization, encryption, and monitoring. Out of scope are specific business logic implementations within individual services.

Functional Requirements

FR1: Ensure secure communication between all microservices

FR2: Protect sensitive data both in transit and at rest

FR3: Authenticate and authorize requests across services

FR4: Detect and prevent unauthorized access or attacks

FR5: Maintain audit logs for security events

Non-Functional Requirements

NFR1: Support at least 1000 concurrent service-to-service calls

NFR2: API response latency p99 under 200ms including security checks

NFR3: Availability target of 99.9% uptime

NFR4: Scalable to add new services without compromising security

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway with authentication and rate limiting

Service Mesh for secure service-to-service communication

Identity Provider for centralized authentication

Token-based authorization (e.g., JWT, OAuth2)

Encrypted communication channels (TLS)

Centralized logging and monitoring system

Design Patterns

Zero Trust Security Model

Defense in Depth

Mutual TLS (mTLS)

Token-based Authentication and Authorization

Audit Logging and Anomaly Detection

Reference Architecture

  +----------------+          +----------------+          +----------------+
  |                |          |                |          |                |
  |  Client/User   |  <--->   |   API Gateway  |  <--->   |  Microservice 1 |
  |                |          | (Auth, RateLim)|          |                |
  +----------------+          +----------------+          +----------------+
                                      |                            |
                                      |                            |
                                      v                            v
                             +----------------+          +----------------+
                             |  Identity      |          |  Microservice 2 |
                             |  Provider      |          |                |
                             +----------------+          +----------------+
                                      |                            |
                                      +------------+---------------+
                                                   |
                                         +--------------------+
                                         | Service Mesh (mTLS) |
                                         +--------------------+

Components

API Gateway

Nginx, Kong, or AWS API Gateway

Entry point for clients; handles authentication, authorization, and rate limiting

Identity Provider

OAuth2 Server, OpenID Connect, Keycloak

Centralized user and service authentication and token issuance

Service Mesh

Istio, Linkerd

Manages secure service-to-service communication with mutual TLS and policy enforcement

Microservices

Any language/framework

Business logic components that validate tokens and enforce authorization

Centralized Logging and Monitoring

ELK Stack, Prometheus, Grafana

Collects security logs and metrics for audit and anomaly detection

Request Flow

1. 1. Client authenticates with Identity Provider and receives a token.

2. 2. Client sends requests with token to API Gateway.

3. 3. API Gateway validates token and enforces rate limits.

4. 4. API Gateway forwards request to target microservice.

5. 5. Microservices communicate with each other over Service Mesh using mutual TLS.

6. 6. Each microservice validates tokens and enforces authorization policies.

7. 7. All security events and access logs are sent to centralized logging for monitoring.

Database Schema

Entities: - User: id, username, hashed_password, roles - ServiceAccount: id, name, credentials - Token: token_id, user_id/service_account_id, expiry, scopes - AuditLog: id, timestamp, service_name, action, user_id, status Relationships: - User has many Tokens - ServiceAccount has many Tokens - AuditLog references User or ServiceAccount for actions

Scaling Discussion

Bottlenecks

API Gateway becoming a single point of failure or bottleneck

Identity Provider overload with authentication requests

Latency added by mutual TLS handshakes in Service Mesh

High volume of logs overwhelming monitoring infrastructure

Solutions

Deploy multiple API Gateway instances behind a load balancer for high availability

Use token caching and refresh tokens to reduce load on Identity Provider

Optimize Service Mesh configuration and use session reuse to reduce TLS overhead

Implement log sampling, aggregation, and scalable storage solutions

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing the architecture and data flow, 10 minutes discussing scaling and security trade-offs, 5 minutes summarizing.

Explain why security must be consistent across all services to prevent breaches

Discuss authentication and authorization mechanisms in microservices

Highlight the role of API Gateway and Service Mesh in enforcing security

Mention encryption in transit and at rest

Address monitoring and audit logging for security visibility

Talk about scaling challenges and mitigation strategies