Quick take
Microservices don’t have a security perimeter. They have dozens. Treat every internal hop as hostile, enforce identity everywhere, encrypt everything in transit, and keep secrets out of code. The rest is details.
When we broke the fintech startup’s monolith into services, the first thing I noticed was how much implicit trust we had been leaning on. One process, one memory space, one set of credentials. Easy. Comfortable. Gone.
Microservices replace that single boundary with a mesh of network calls, each one a potential point of compromise. Every background job, every inter-service HTTP call, every gRPC stream – all of it’s attack surface now. NATO cyber defense drills one thing into you: assume the network is compromised. That mindset translates directly to microservices.
This post is what I wish I’d had when we started. Practical patterns, not theory.
Start With a Threat Model
Before writing a single line of security code, sit down and think about what can go wrong. Not in the abstract. Specifically.
At the fintech startup we built our threat model around a simple premise: any internal network segment can be observed or spoofed. Paranoid? Maybe. But it forces you to build real defenses instead of relying on the warm blanket of a private VPC.
The risks that keep me up at night:
- Stolen or replayed tokens granting access long after they should
- Lateral movement – one compromised service becoming a beachhead into everything
- Over-privileged service accounts that can read data they have no business touching
- Sensitive data leaking through logs, traces, or error messages
- Secrets baked into container images or checked into git
If your threat model doesn’t scare you a little, it’s not honest enough.
Authentication: Who Are You?
Gateway Auth for External Traffic
Centralize user authentication at the API gateway. Validate the token once, attach identity headers, forward to internal services over trusted channels. Done.
Client -> API Gateway -> Services
validate token
attach identity headers
This keeps individual services simple. They don’t need to know about OAuth flows or token validation libraries. They just read a header. The critical trade-off: internal services must reject anything that didn’t come through the gateway. If a service accepts direct traffic, you’ve defeated the entire pattern.
Service-to-Service Identity
This is where most teams get sloppy. Internal calls between services need identity too. “It’s internal” isn’t an authentication strategy.
Two options that work:
Mutual TLS. Both sides present certificates from a trusted internal CA. Authenticates the caller, authenticates the receiver, encrypts the wire. This is the gold standard. We used it at the fintech startup for anything touching financial data.
Short-lived service tokens. JWT or similar, with a tight expiry and explicit audience claim. Works well when you can’t run a full mesh or when edge systems call internal APIs.
Pick one. Enforce it everywhere. No exceptions for “low-risk” services – those are the ones attackers pivot through.
Authorization: What Can You Do?
Authentication tells you who’s calling. Authorization decides if they’re allowed. These are separate concerns and you should keep them that way.
Centralized Policy Service
A dedicated authorization service that evaluates allow/deny decisions. You send it “service X wants to do Y on resource Z” and it answers.
Service -> AuthZ Service -> Decision
Good for complex, frequently changing rules. Good for audit trails. Bad for latency-sensitive paths – you’re adding a network hop to every decision. At the fintech startup we used this for anything involving user data access decisions. The latency hit was worth the consistency.
Embedded Policy Evaluation
Each service evaluates policy locally using a shared library or rules engine. No network hop. Fast. The downside is keeping policies in sync across dozens of services. One stale deployment and you’ve got inconsistent authorization.
Use this for latency-critical paths where the rules are stable and well-understood.
Token-Embedded Permissions
Stuff roles or scopes into the JWT itself. Simple, no extra calls needed. But tokens are snapshots – if you revoke a permission, every unexpired token still carries the old grants. Keep expiry times short. Minutes, not hours.
Works for coarse-grained access control. Falls apart when you need fine-grained, data-specific rules.
Encrypt Everything in Transit
Not just external traffic. All of it. Service-to-service, service-to-database, service-to-cache. Everything.
“But it’s a private network.” I don’t care. Private networks get breached. Network segmentation gets misconfigured. A single compromised host with tcpdump running will capture every unencrypted call in the segment.
Mutual TLS or a service mesh handles this with minimal code changes. Encryption alone doesn’t replace authorization, but it kills passive eavesdropping and makes man-in-the-middle attacks dramatically harder.
Field-Level Encryption for Sensitive Data
Some fields need protection beyond transport encryption. Payment card numbers, national IDs, health data – encrypt these at the application layer. If an intermediate proxy logs the request body or a tracing system captures the payload, the sensitive fields are still opaque.
We learned this the hard way at the fintech startup when a debug log captured a full API response including user financial preferences. Transport encryption didn’t help because the log was written on the receiving end.
Secrets Management
Hardcoded secrets are a gift to attackers. Secrets in environment variables are only slightly better – they show up in process listings, crash dumps, and container inspection output.
What actually works:
- A real secrets manager. Vault, AWS Secrets Manager, whatever. Not a config file.
- Short-lived credentials that expire before they can be exfiltrated and reused.
- Rotation on a schedule and immediately after any incident.
- No developer workstation has production secrets by default. Full stop.
The running process fetches secrets at runtime. Nothing is baked into the image. Nothing lives in source control. If I can find your database password in a git history, your security posture is theater.
Defense in Depth
No single control is enough. Layer them.
Network Segmentation
Default-deny between services. If service A doesn’t need to talk to service B, block it. Use network policies based on service identity, not IP addresses. IPs change. Service names don’t.
Input Validation on Every Boundary
Even internal calls. Especially internal calls. A compromised service sending malformed data to a downstream service shouldn’t be able to trigger a buffer overflow or SQL injection. Strict schemas, fail fast on anything unexpected.
This was hammered into us during NATO exercises. The perimeter isn’t the only place attacks happen. Assume any input can be hostile.
Least Privilege Everywhere
If a service only reads from a database table, its credentials shouldn’t allow writes. If a service only calls two other services, its network policy should block everything else. Shared credentials across services are a lateral movement highway.
Resilience Controls as Security
Circuit breakers, rate limits, and timeouts aren’t just reliability features. They’re security controls. A compromised service trying to exfiltrate data through a downstream API gets stopped by rate limits. A denial-of-service attempt gets contained by circuit breakers.
Observability Without Leaking
Log authentication failures. Log authorization decisions. Log admin actions. Use consistent request IDs so you can trace a request across services during an incident.
But – and this matters – don’t log the sensitive data itself. Log metadata. Redact by default. I’ve seen security logging implementations that were themselves a data breach waiting to happen because they captured full request bodies “for debugging.”
The goal is answering four questions fast: who did what, when, and from where.
What I’d Tell You Over Coffee
Microservices security isn’t a product you buy or a checklist you complete. It’s a set of boring, consistent patterns applied everywhere. Mutual TLS, short-lived tokens, least privilege, secrets in a vault, encrypted transit, validated inputs, observable decisions.
None of this is glamorous. Most of it’s plumbing. But I’ve seen what happens when that plumbing leaks, both in military contexts and in production systems handling real user data. The organizations that stay safe are the ones that got the fundamentals right and kept them right, not the ones that bought the fanciest tools.
Build it into the platform so individual services get security by default. Make the secure path the easy path. That’s the whole game.