Production-ready basics every service needs: security, externalized configuration and a microservice chassis.
key idea / coordinatorservice / good pathin progress / watch outproblem / failureneutral
Beyond working code
Before production a service must also be secure, configurable and observable.
Security
In a monolith one session holds the user. With services the gateway authenticates and passes a token.
Defense in depth and the five functions
Tokens and TLS are only part of security. Two older principles come first. Least privilege: give a party the minimum access it needs, for the shortest time, so a stolen read-only credential is worth little. Defense in depth: never rely on one barrier, like a castle with a hill and two walls. From Building Microservices, ch. 11.
Start with threat modeling: think like an attacker and look at the whole system. Securing one or two services leaves a strong front door and an open window. Weave security into delivery, for example by scanning dependencies on every CI build.
Credentials, patching and data protection
Services multiply credentials: more machines, databases and service accounts. Treat them as a design topic. From Building Microservices, ch. 11.
Foundation
What to do
Patching
The 2017 Equifax breach used an unpatched library. Scan dependencies (Snyk, GitHub code scanning) and fail the build on known holes.
Backups
Restore them regularly: an untested backup is a "Schrödinger backup". Keep them isolated, such as a separate cloud account, and encrypted.
Rebuild
Automate so you can rebuild a compromised system on demand.
Data at rest: use well-known, reviewed encryption and never invent your own. Hash passwords with salt. Encrypt data when you first see it, decrypt only on demand, and encrypt backups. Be frugal: data you do not store cannot be stolen. Keep sensitive values out of logs.
From Bootstrapping Microservices: keep secrets out of code and scripts. The CD workflow reads them from GitHub secrets (even the Base64 kubeconfig). Avoid Terraform outputs for sensitive values, because they end up in plain text in the state file.
Trust between services
Where to authorize
Idea
Catch
Upstream (gateway)
Check once, trust everything downstream
Implicit trust; the gateway must know every service
In each service
Service decides using claims in the JWT
Services need the user identity and roles
Keep roles coarse-grained and shaped like your organization. Roles such as CALL_CENTER_50_DOLLAR_REFUND push one service's rules into the directory and tie its life cycle to another team.
Configuration
Build once, deploy to many environments. Supply settings at runtime.
Microservice chassis
Do not rebuild these cross-cutting concerns in every service.
Recap
The API gateway authenticates and passes a JWT access token to services.
Services authorize using the roles in the token plus their own data rules.
Externalize configuration: push via env vars or pull from a config server.
Apply least privilege and defense in depth across identify, protect, detect, respond and recover. Use per-instance credentials, TLS or mTLS, encrypted data and signed user identity (JWT) so services can authorize.
Use a chassis for the basics and a service mesh for networking.
Quick check
Why pass a JWT instead of an opaque token, and what is the catch?Show answer
A JWT carries signed identity and roles, so services check it without calling a security service. It cannot be revoked, so it is short-lived and renewed with a refresh token.