Principles for securing microservices architectures

Securing a microservices architecture means protecting every service, every communication channel, and every data store as if each is independently exposed to the internet—because in a zero-trust model, it is. Unlike a monolith where a single security perimeter protects the entire application, microservices multiply the attack surface: every service is a potential entry point, every inter-service API call is a potential interception target, and every container image is a potential supply chain vector. In system design interviews, microservices security is tested as a design dimension alongside scalability and availability. Interviewers evaluate whether you treat security as an architectural principle applied from the start or a feature bolted on at the end. Organizations implementing zero-trust architectures for microservices reported 67% fewer security incidents related to service-to-service communications, according to industry research—a statistic that validates the approach interviewers expect you to describe.

Key Takeaways

• Zero trust is the governing principle: every request is authenticated and authorized regardless of network location. An attacker who compromises one service cannot move laterally to others without valid credentials and authorization.
• mTLS (mutual TLS) between all services is the baseline for inter-service communication security. A service mesh (Istio, Linkerd) automates mTLS certificate management, rotation, and enforcement without application code changes.
• The API gateway is the security perimeter for external traffic: TLS termination, authentication (JWT/OAuth), rate limiting, input validation, and WAF protection. Internal traffic uses a separate security model (mTLS + service identity).
• Secrets management (HashiCorp Vault, AWS Secrets Manager) replaces hardcoded credentials, environment variables, and config files. Secrets are injected at runtime, rotated automatically, and never stored in source code or container images.
• Supply chain security is the fastest-growing attack vector. Scan dependencies in CI/CD (Dependabot, Snyk), sign container images (cosign, Notary), use minimal base images (distroless), and maintain a Software Bill of Materials (SBOM) for every deployed service.

Principle 1: Zero Trust — Never Trust, Always Verify

Traditional perimeter security assumes everything inside the VPC is safe. Zero trust assumes nothing is safe. Every request—external or internal—must prove its identity and authorization before accessing any resource.

What zero trust means for microservices:

Every service-to-service call requires authentication (mTLS certificates or internal JWTs). Every request is authorized against a policy engine (who can call which endpoint with which parameters). No service has more access than it needs (principle of least privilege). Network location grants zero implicit trust—an attacker inside the VPC is treated identically to an attacker on the internet.

Why it matters: In a microservices architecture with 50+ services, compromising a single service (through a vulnerability, misconfiguration, or supply chain attack) gives the attacker a foothold inside the network. Without zero trust, that foothold provides access to every other service on the internal network. With zero trust, the compromised service cannot reach any service it is not explicitly authorized to call.

Interview application: "I would design this system with a zero-trust model. Every inter-service call requires mTLS authentication. The payment service only accepts calls from the order service and the refund service—enforced by authorization policies in the service mesh, not by network rules alone. Even if an attacker compromises the notification service, they cannot reach the payment service because the notification service's identity is not authorized for payment endpoints."

Principle 2: Mutual TLS — Encrypting and Authenticating Every Hop

mTLS extends standard TLS by requiring both the client and server to present certificates and verify each other's identity. Standard TLS only authenticates the server (the client verifies the server's certificate); mTLS adds client authentication so the server also verifies the client's identity.

How it works in microservices: Each service has a unique certificate issued by an internal certificate authority (CA). When Service A calls Service B, both present their certificates. Service B verifies that Service A's certificate is valid and was issued by the trusted CA. The connection is encrypted and both identities are confirmed.

Service mesh automation: Manually managing certificates for 50+ services is operationally infeasible. Service meshes (Istio, Linkerd) automate the entire lifecycle: certificate issuance, distribution, rotation, and revocation. The Envoy sidecar proxy handles mTLS transparently—application code never touches certificates.

Performance impact: mTLS adds approximately 1–2ms of latency per hop for the TLS handshake. With persistent connections (connection pooling between services), the handshake occurs once per connection, not per request—reducing the ongoing overhead to near zero after initial setup.

Interview application: "I would deploy Istio as the service mesh to handle mTLS automatically across all services. Each service receives a SPIFFE identity certificate rotated every 24 hours. The Envoy sidecar proxy terminates mTLS on both sides of every inter-service call. The application code is completely unaware of the security layer—it makes plain HTTP calls to localhost, and the sidecar encrypts and authenticates transparently."

Principle 3: API Gateway — The External Security Perimeter

The API gateway is the single entry point for all external traffic. It handles security concerns that should never be duplicated across individual services.

Gateway security responsibilities:

TLS termination: Decrypt incoming HTTPS traffic. All external communication uses TLS 1.3. Authentication: Validate JWT tokens or OAuth 2.0 access tokens. Reject unauthenticated requests before they reach any backend service. Rate limiting: Enforce per-client limits (token bucket, 100 requests/minute for free tier, 1,000 for paid). Return 429 with Retry-After header. Input validation: Reject malformed requests, oversized payloads, and requests with suspicious patterns (SQL injection attempts, XSS payloads). WAF integration: AWS WAF or Cloudflare WAF blocks known attack patterns, bot traffic, and DDoS attempts at the edge.

The critical separation: External traffic enters through the API gateway (JWT authentication, rate limiting, WAF). Internal traffic flows through the service mesh (mTLS, service identity, authorization policies). These are separate security models with different trust levels. Never expose internal services directly to external traffic.

Principle 4: Authentication and Authorization — Who and What

Authentication (who is this?): For external users: OAuth 2.0 with JWT access tokens. Tokens are validated at the API gateway—individual services trust the gateway's validation. For service-to-service: mTLS certificates provide cryptographic identity. SPIFFE (Secure Production Identity Framework for Everyone) provides standardized workload identity.

Authorization (what can they do?): For external users: Scoped OAuth tokens limit what each client application can access (read:orders, write:payments). For service-to-service: Authorization policies in the service mesh define which service identities can call which endpoints. The order service can call the payment service's /charge endpoint but not its /refund endpoint.

Policy-as-code: Use Open Policy Agent (OPA) to define authorization rules as code, version-controlled in Git, and evaluated at runtime. This ensures authorization logic is consistent, auditable, and reviewable in pull requests—not scattered across application code in dozens of services.

Interview application: "External users authenticate via OAuth 2.0 at the API gateway. The gateway validates the JWT and passes the user_id and scopes downstream via headers. Service-to-service authorization is enforced by Istio's AuthorizationPolicy—I define which source workloads can access which destination endpoints. OPA evaluates complex authorization rules that Istio's built-in policies cannot express."

Principle 5: Secrets Management — No Credentials in Code

Hardcoded credentials, API keys in environment variables, and secrets in configuration files are the most common security failures in microservices. A single leaked secret compromises the service and every system it connects to.

The solution: Centralized secrets management with runtime injection.

HashiCorp Vault or AWS Secrets Manager stores all secrets (database passwords, API keys, PSP credentials, encryption keys). Secrets are injected into services at runtime via sidecar or init container—never baked into container images. Automatic rotation changes secrets on a schedule (every 30–90 days) without service restarts. Audit logging records every secret access: who accessed which secret, when, and from where.

Kubernetes-native approach: Kubernetes Secrets (base64-encoded, not encrypted by default) are insufficient for production. Use External Secrets Operator to sync secrets from Vault or AWS Secrets Manager into Kubernetes, or use Vault's sidecar injector to inject secrets directly into pods.

Principle 6: Container and Supply Chain Security

Every container image is a potential vector for supply chain attacks. A compromised dependency, a malicious base image, or a tampered build artifact can introduce vulnerabilities into production without any code changes.

Image security: Use minimal base images (distroless, Alpine) to reduce the attack surface—fewer packages mean fewer vulnerabilities. Scan images for known vulnerabilities in the CI/CD pipeline using Trivy, Grype, or Snyk Container. Fail the build on critical or high-severity findings.

Dependency scanning: Scan application dependencies with Dependabot (GitHub), Snyk, or FOSSA. Pin dependency versions to prevent silent updates. Review updates before adopting them—do not auto-merge dependency changes without review.

Image signing and verification: Sign container images using cosign or Notary after building. Verify signatures before deployment—Kubernetes admission controllers (Kyverno, OPA Gatekeeper) reject unsigned images. This ensures only images built by your CI/CD pipeline run in production.

SBOM (Software Bill of Materials): Generate and maintain an SBOM for every deployed service listing all dependencies and their versions. When a new CVE is published, query the SBOM to identify affected services in minutes instead of hours.

Principle 7: Network Segmentation and Runtime Protection

Network policies: Kubernetes NetworkPolicies restrict which pods can communicate with which other pods. Default to deny-all ingress and egress, then explicitly allow only the required communication paths. This limits lateral movement if a service is compromised.

Runtime security: Tools like Falco monitor container behavior at runtime and alert on anomalous activity: unexpected process execution, suspicious file access, network connections to unusual destinations. Runtime detection catches attacks that static scanning misses—zero-day exploits and novel attack patterns.

Egress control: Restrict which external endpoints services can reach. A user profile service has no business calling external URLs. An attacker who compromises it should not be able to exfiltrate data to an external server. Egress policies whitelist only the specific external endpoints each service needs (payment PSP domains, email provider APIs, logging services).

Immutable infrastructure: Deploy containers as immutable artifacts. Never SSH into running containers to make changes. If a container is compromised, it can be replaced with a clean image instantly. Immutability ensures that runtime modifications—whether from attackers or configuration drift—are detected and eliminated on every deployment cycle.

For structured practice integrating security principles into complete system design solutions, Grokking the System Design Interview covers security as a non-functional requirement in every design problem. For advanced security patterns including zero-trust architecture at scale, multi-region secret management, and production-grade service mesh configurations, Grokking the Advanced System Design Interview builds the depth required for L6+ interviews. The system design interview guide provides the broader framework for approaching any system design problem.

Frequently Asked Questions