3 Service-to-service communication

This chapter emphasizes that securing service-to-service communication is fundamental to trustworthy microservice systems. It frames four universal security problems every application must solve: securing communication channels, implementing authentication and authorization, protecting sensitive credentials, and operating safely in cloud or on‑prem environments. Because a single user action can traverse a deep call graph of independently deployed services, the chapter stresses end-to-end protection of that chain and equips developers with a practical toolbox of technologies and patterns to keep interactions confidential, authenticated, and authorized.

The central technical challenges revolve around identity. First, user identity must be propagated across heterogeneous protocols (HTTP, RPC, messaging, events) and languages so downstream services can enforce least privilege; there is no single industry standard, so teams combine conventions with technologies like OAuth2/OpenID Connect and JOSE-based tokens. Second, services must authenticate to each other to make authorization decisions—commonly via API keys or mutual TLS. API gateways help manage and validate keys and protect the edge, while mTLS—often enabled by a service mesh and strengthened with SPIFFE—authenticates workloads and encrypts every hop by default.

The chapter also ties application-layer security to runtime hardening on Kubernetes. Secure operation requires: building secure container images, running on a locked‑down cluster provided by platform engineering, and shipping deployment manifests that enable security controls and follow best practices. Developers are accountable for image hygiene and secure YAML, while the platform enforces cluster guardrails. Finally, it compiles the must‑know stack for developers: TLS, OAuth2/OIDC, WebAuthn, credential storage services, API gateways, service mesh, SPIFFE, cloud‑native buildpacks, and Kubernetes—grounded in AES, JOSE, and X.509, and underpinned by core cryptographic primitives such as hashing, MACs, symmetric and public‑key cryptography, and key exchange.

Potential microservices that can be easily spotted from a product page: product search microservice, look inside microservice, book details microservice (title, author, publication date, summary), product rating microservice, pricing microservice that can calculate discounts dynamically, delivery estimation microservice that computes when order arrives at a customer’s address and shipping costs

An HTTP request to the product page microservice service fans out through multiple layers of supporting microservices, this is what we mean by the call service-to-service call graph. Organizations can have hundreds of microservices that interact with each other.

A generic call graph showing edge microservices that receive user requests and then call internal microservices to handle the request. How can a microservice determine the user's identity that initiated the request? How can a microservice determine the identity of the service that called it?

The edge service uses OpenID Connect or WebAuthn protocols to determine the identity of the user making the request. It must then propagate the user identity over HTTP to the service written in C#, which must propagate the user identity over gRPC to the service written in Go, which must propagate the user identity over AMQP to the service written in JavaScript.

Some services, like inventory, do not need to know the identity of the customer who is viewing a product page to return the current inventory level.

The book teaches you the standards, protocols, and patterns for building secure applications using practical sample applications. The goal is to set you up for success on your security learning journey by teaching you foundational technologies every developer should know.

• Microservice architectures decompose applications into independently deployable services that communicate through service-to-service calls, creating complex call chains.
• Edge microservices interact directly with users and external systems, while internal microservices receive requests from other microservices within the system.
• User identity propagation through service call chains requires passing user credentials across different programming languages and network protocols like HTTP, gRPC, and AMQP.
• No industry standard exists for propagating user identity between services, requiring custom solutions using patterns and conventions.
• Service identity can be established through API keys or mutual TLS authentication to authorize which services can perform specific operations.
• API gateways simplify implementation of API key patterns for service authentication and authorization.
• Service mesh technologies like Istio simplify deployment and management of mutual TLS between microservices.
• Developers must learn to create secure container images and write Kubernetes deployment manifests following security best practices.
• Platform engineering teams are responsible for providing secure Kubernetes clusters, while developers handle secure application packaging and deployment configuration.
• Essential security technologies for developers include TLS, OAuth2/OpenID Connect, WebAuthn, credential storage services, API gateways, service mesh, SPIFFE, Cloud Native Buildpacks, and Kubernetes.
• These technologies depend on foundational knowledge of AES encryption, JOSE standards, X.509 digital certificates, and cryptographic primitives like hash functions and public key cryptography.
• DevOps has evolved from separated development and operations teams to integrated teams responsible for both building and running applications in production.

FAQ