Give every microservice a security contract for identity, traffic, and failure

Bottom line: splitting an application into smaller services also distributes trust and failure decisions. Every service needs an explicit contract describing who may call it, what may be requested, how communication is protected, how resources are bounded, what evidence is produced, and how the service behaves when dependencies fail.

Source fact: what NIST identifies

NIST SP 800-204 analyzes security strategies for microservices-based applications. NIST notes that microservices commonly communicate through APIs and identifies core features that include authentication and access management, service discovery, secure communications, security monitoring, availability and resiliency techniques, load balancing and throttling, integrity assurance when introducing services, and session persistence. The publication also discusses architectural frameworks such as API gateways and service meshes.

The source supports treating those features as part of application security design rather than assuming service decomposition supplies them automatically.

What the source does not establish

Microservices are not inherently more secure than a monolith, and the publication does not certify a framework or deployment. A shared gateway can apply common controls, but it cannot infer every service’s business authorization rules. Encryption between services does not establish that the caller should perform the requested action.

The right design depends on data classification, service criticality, transaction behavior, consistency requirements, deployment platform, dependency graph, and acceptable failure modes.

Applicability questions

• Which identities call the service, and how are human, workload, and administrative identities distinguished?
• What operations and data are authorized for each caller and context?
• How is the service discovered, and what prevents a caller from reaching an unintended instance or path?
• What limits apply to request rate, concurrency, payload size, retries, and downstream consumption?
• Which events allow an operator to reconstruct a distributed transaction without placing secrets in logs?

DSE recommendation: write and test a service contract

The following steps are DSE recommendations based on the cited source.

1. Record the service owner, purpose, interfaces, data handled, callers, dependencies, administrative path, deployment identity, and retirement plan.
2. Define authentication and authorization separately. State the accepted identity, audience, operation, resource scope, and any current business context required for the decision.
3. Specify communication and discovery requirements, including protected protocols, trusted endpoints, name or identity validation, certificate or key ownership, and rotation behavior.
4. Define resource and failure controls: timeouts, bounded retries, throttling, circuit breaking, back-pressure, and behavior when an identity, policy, or dependency is unavailable.
5. Assign common controls to gateways, meshes, or platform services where they can be applied consistently. Keep service-specific controls and ownership visible.
6. Version the contract with the interface and test both allowed and denied flows during release.

Verification and evidence

For a representative service, retain the contract, data-flow diagram, identity and authorization tests, protocol configuration, discovery and endpoint tests, resource-limit results, failure injection results, telemetry examples, and deployment record. Confirm that observed runtime flows match the approved caller and dependency list.

Official references

• NIST SP 800-204 — Security Strategies for Microservices-based Application Systems — National Institute of Standards and Technology; published August 2019
• NIST SP 800-204A — Building Secure Microservices-based Applications Using Service-Mesh Architecture — National Institute of Standards and Technology