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

Practice

1. Why is it important to include security measures in every microservice rather than just at the entry point?

easy

A. Because security slows down the system if applied everywhere.

B. Because only the first service handles sensitive data.

C. Because each service can be accessed independently and needs protection.

D. Because microservices do not communicate with each other.

Solution

1. Step 1: Understand microservice independence

   Each microservice can be called directly or by other services, so it can be a target for attacks.

2. Step 2: Recognize the need for protection at all points

   If only the entry point is secured, other services remain vulnerable to unauthorized access.

3. Final Answer:

   Because each service can be accessed independently and needs protection. -> Option C

4. Quick Check:

   Security must cover all services = C [OK]

Hint: Remember: every door needs a lock, not just the front door [OK]

Common Mistakes:

• Thinking only the first service needs security
• Assuming microservices don't communicate
• Believing security everywhere slows system too much

2. Which of the following is the correct way to enforce security in a microservice?

easy

A. Apply authentication only at the API gateway.

B. Disable auditing to reduce storage costs.

C. Skip authorization checks inside services to improve speed.

D. Use encryption for data in transit and at rest within each service.

Solution

1. Step 1: Identify proper security practices

   Encryption protects data both when moving between services and when stored inside each service.

2. Step 2: Evaluate other options

   Authentication only at gateway leaves internal services vulnerable; skipping authorization and auditing weakens security.

3. Final Answer:

   Use encryption for data in transit and at rest within each service. -> Option D

4. Quick Check:

   Encryption everywhere = B [OK]

Hint: Encrypt data everywhere, not just at the edges [OK]

Common Mistakes:

• Thinking authentication at gateway is enough
• Ignoring authorization inside services
• Disabling auditing to save space

3. Consider a microservice architecture where Service A calls Service B. If Service A authenticates the user but Service B does not verify the user's permissions, what is the likely outcome?

medium

A. Service B will reject all requests from Service A.

B. Service B may perform unauthorized actions on behalf of the user.

C. Service A will automatically enforce permissions on Service B.

D. The system will be faster and more secure.

Solution

1. Step 1: Analyze authentication vs authorization

   Authentication confirms identity; authorization checks permissions. If Service B skips authorization, it trusts Service A blindly.

2. Step 2: Understand security risk

   Without permission checks, Service B may allow actions the user is not allowed to perform, causing security breaches.

3. Final Answer:

   Service B may perform unauthorized actions on behalf of the user. -> Option B

4. Quick Check:

   Authorization missing in called service = A [OK]

Hint: Authenticate once, authorize everywhere [OK]

Common Mistakes:

• Assuming authentication covers authorization
• Believing Service A controls permissions for Service B
• Thinking skipping checks improves security

4. A developer forgot to add encryption for data stored in Service C, while all other services use encryption. What is the main security risk introduced?

medium

A. Data in Service C can be read if storage is accessed by attackers.

B. Service C will reject all incoming requests.

C. Encryption is not needed if network is secure.

D. Other services will stop working due to mismatch.

Solution

1. Step 1: Identify impact of missing encryption at rest

   Without encryption, stored data in Service C is vulnerable to theft if storage is compromised.

2. Step 2: Evaluate other options

   Service C will not reject requests just because of missing encryption; network security does not protect stored data; other services remain unaffected.

3. Final Answer:

   Data in Service C can be read if storage is accessed by attackers. -> Option A

4. Quick Check:

   Missing encryption at rest = D [OK]

Hint: Encrypt stored data to prevent leaks [OK]

Common Mistakes:

• Assuming network security protects stored data
• Thinking missing encryption breaks service functionality
• Believing other services fail due to one missing encryption

5. You are designing a microservices system handling sensitive user data. Which combination of security practices ensures comprehensive protection across all services?

hard

A. Authentication and authorization in each service, encryption in transit and at rest, and distributed auditing.

B. Authentication at gateway, no encryption inside services, centralized auditing.

C. No authentication, encryption only at database, auditing only on gateway.

D. Authentication only in some services, no authorization, encryption only in transit.

Solution

1. Step 1: Identify key security components

   Authentication and authorization must be enforced in every service to verify identity and permissions.

2. Step 2: Ensure data protection and monitoring

   Encryption protects data both moving and stored; auditing across services tracks actions for accountability.

3. Step 3: Evaluate options

   Authentication and authorization in each service, encryption in transit and at rest, and distributed auditing. covers all these best practices; others miss critical elements like authorization or encryption.

4. Final Answer:

   Authentication and authorization in each service, encryption in transit and at rest, and distributed auditing. -> Option A

5. Quick Check:

   Complete security coverage = A [OK]

Hint: Secure identity, data, and logs everywhere [OK]

Common Mistakes:

• Relying only on gateway security
• Skipping authorization checks
• Ignoring encryption at rest or auditing