Security, Privacy, and Zero Trust

Introduction

Microservices improve independent deployment, scaling, and organizational autonomy, but they also enlarge the security boundary. A monolithic application may expose one principal network interface and one authorization model. A microservices ecosystem can contain dozens of services, message brokers, API gateways, databases, service meshes, build pipelines, cloud accounts, administrators, and third-party integrations. Each interaction creates an opportunity for impersonation, unauthorized access, data leakage, tampering, or service disruption.

Security in microservices is therefore not a single gateway feature. It is a system property created through identity, authentication, authorization, encryption, secure software supply chains, privacy engineering, operational monitoring, and effective governance. Zero Trust provides a useful organizing principle: no user, device, workload, network location, or service is automatically trusted merely because it is inside a corporate network or cluster.

This chapter examines how to design secure service ecosystems using threat modeling, identity and access management, OAuth 2.0, OpenID Connect, JSON Web Tokens, mutual TLS, least privilege, API security, supply-chain controls, secrets management, privacy engineering, and compliance practices.

Learning Objectives

After studying this chapter, you should be able to:

1. Identify major threats in distributed service architectures.
2. Apply Zero Trust principles to users, services, devices, and operational processes.
3. Distinguish authentication, authorization, identity federation, and accountability.
4. Explain practical uses and limitations of OAuth 2.0, OpenID Connect, JWT, and mutual TLS.
5. Design least-privilege access policies for APIs, databases, and service accounts.
6. Recommend controls for API security, secrets, dependencies, containers, and deployment pipelines.
7. Apply privacy-by-design principles and relate security controls to compliance obligations.
8. Analyze security trade-offs in a realistic microservices case.

1. The Security Context of Microservices

A microservices system has several security planes:

• User plane: browsers, mobile applications, partners, and human identities.
• Service plane: calls between services, asynchronous messages, and scheduled jobs.
• Control plane: deployment systems, orchestration platforms, service meshes, configuration systems, and administrative consoles.
• Data plane: databases, object stores, caches, logs, backups, and analytics platforms.
• Software supply-chain plane: source repositories, package registries, build runners, container images, and signing systems.

A compromise in one plane can affect another. For example, a vulnerable dependency may allow code execution in a service; excessive service permissions may then allow access to customer records; weak logging may prevent investigators from determining what occurred.

The distributed nature of microservices creates several recurring risks:

• Confused deputy attacks: a service uses its own broad authority to perform an operation that the calling user was not permitted to request.
• Identity propagation errors: a downstream service cannot distinguish the original user from the intermediary service.
• Trust-zone assumptions: internal network location is treated as proof of legitimacy.
• Credential proliferation: many services require passwords, tokens, certificates, or API keys.
• Inconsistent enforcement: different services interpret roles, scopes, and tenant boundaries differently.
• Observability exposure: logs and traces accidentally contain tokens, personal data, or payment information.
• Blast-radius expansion: one compromised workload can reach many other resources.

Security architecture must address both direct attacks and failures of system design.

2. Threat Modeling for Service Ecosystems

Threat modeling is a structured method for identifying what must be protected, from whom, and by which controls. It should begin during architecture and continue when services, data flows, vendors, or deployment methods change.

A practical process is:

1. Define assets. Examples include access tokens, customer identity data, payment records, signing keys, source code, administrative functions, and availability.
2. Identify actors. Consider customers, employees, administrators, malicious insiders, compromised devices, external attackers, suppliers, and compromised services.
3. Map trust boundaries and data flows. Document API calls, events, databases, queues, external identity providers, and management interfaces.
4. Enumerate threats. Spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege are useful categories. This is commonly summarized as STRIDE.
5. Assess risk. Consider likelihood, impact, exposure, and existing controls. A high-impact threat with uncertain likelihood still deserves explicit treatment.
6. Select mitigations. Prefer preventive controls, then detective and recovery controls.
7. Validate and monitor. Test assumptions through code review, penetration testing, configuration assessment, and incident exercises.

A data-flow diagram should show whether an access token is passed to a downstream service, whether the downstream service independently authorizes the action, and whether sensitive data crosses a boundary. Threat models should include nonfunctional concerns such as availability, privacy, safety, and legal obligations.

Security Requirements from Threats

Threats should become testable requirements. For example:

3. Zero Trust as an Architectural Model

Zero Trust is not a product and does not mean that every request is denied. It means that access decisions are explicit, continuously evaluated, and based on evidence rather than network location.

Core principles include:

• Verify explicitly using identity, device, workload, request, and contextual information.
• Apply least-privilege access with narrowly defined permissions.
• Assume breach and design to limit lateral movement and blast radius.
• Separate control-plane administration from ordinary application traffic.
• Continuously monitor, evaluate, and adapt access decisions.
• Protect data in transit and at rest.

In a Zero Trust microservices design, a request may be evaluated using:

• authenticated subject or workload identity;
• requested operation and resource;
• token issuer, audience, scope, and expiry;
• tenant or organizational boundary;
• device posture or workload attestation;
• network and geographic context;
• risk signals and rate limits;
• data classification and regulatory restrictions.

Zero Trust does not eliminate trust. It makes trust conditional, specific, observable, and revocable. For example, a payment service may accept calls only from a particular workload identity, over mutually authenticated TLS, with a token limited to the payment operation and the correct audience.

4. Identity, Authentication, and Authorization

Identity represents an entity such as a person, service, device, or workload. Authentication establishes evidence that the entity controls a credential. Authorization determines what an authenticated entity may do. Accounting or auditing records relevant actions so that they can be investigated and attributed.

These concepts must not be conflated. A valid login does not imply permission to read every customer record. A service certificate proves possession of a private key but does not by itself authorize access to a particular database table.

Human and Workload Identities

Human identities are generally managed through an identity provider, often with federation to an organization or external provider. Controls may include multifactor authentication, phishing-resistant credentials, conditional access, account lifecycle management, and privileged access workflows.

Workload identities represent services, jobs, or processes. They should be issued through an automated identity system rather than embedding long-lived usernames and passwords in source code. Workload identity may be represented by certificates, signed tokens, cloud-native identities, or service-account credentials.

A service should not share one identity with many unrelated services. Separate identities improve attribution, policy precision, rotation, and incident containment.

Least Privilege

Least privilege grants only the permissions required for a defined task, for the required duration, in the required environment. It applies to users, services, databases, queues, CI runners, administrators, and machines.

Good practice includes:

• separate read and write permissions;
• resource-level rather than system-wide access;
• short-lived credentials;
• just-in-time administrative elevation;
• separate production and development identities;
• explicit tenant restrictions;
• periodic access review;
• deny-by-default policies.

Least privilege must be meaningful. A role called service-reader is not restrictive if it can read every database and every tenant.

5. OAuth 2.0 and OpenID Connect

OAuth 2.0 is an authorization framework. It allows a client to obtain an access token for a resource server without receiving the resource owner’s password. OAuth does not, by itself, define how a user proves identity to the client.

OpenID Connect (OIDC) adds an identity layer on top of OAuth 2.0. It defines an ID token and standard identity claims so that a client can verify who authenticated and obtain interoperable identity information.

Important OAuth Roles

• Resource owner: often the user who controls a resource.
• Client: an application requesting access.
• Authorization server: issues tokens after authenticating and authorizing the request.
• Resource server: API that accepts and validates access tokens.

Common Flows

For browser and mobile applications, Authorization Code with Proof Key for Code Exchange (PKCE) is generally preferred. PKCE binds the authorization request to a verifier known by the legitimate client, reducing the value of an intercepted authorization code.

The client-credentials grant is appropriate for machine-to-machine access where no end user is involved. It represents the client workload, not a human user.

The resource-owner-password grant should not be used in new systems because it requires the client to handle user passwords and undermines federation and multifactor security.

Scopes and Audiences

A scope describes an intended permission, such as orders.read or payments.submit. An audience identifies the API for which a token is intended. A resource server should validate both. A token issued for the profile API should not automatically be accepted by the payment API.

Authorization servers and resource servers should also validate issuer, signature, algorithm policy, expiration, and relevant subject or tenant claims. A token’s presence is not sufficient authorization; the resource server must check whether the requested operation is permitted for the subject and resource.

6. JSON Web Tokens

A JSON Web Token is a compact representation of claims. A signed JWT commonly contains a header, payload, and signature. The claims may include iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not-before time), iat (issued-at time), and jti (token identifier).

A signed JWT provides integrity and issuer authenticity when the signature is correctly verified. It does not provide confidentiality. Anyone who can read the token can generally read its payload. Sensitive information should not be placed in an ordinary signed JWT unless exposure is acceptable. Encryption requires an appropriate encrypted-token design, but minimizing claims is usually preferable.

Resource servers should:

1. obtain trusted issuer metadata and keys;
2. restrict accepted signing algorithms;
3. verify the signature and key identity;
4. validate issuer, audience, expiry, and not-before claims;
5. apply clock-skew policy carefully;
6. enforce scopes, roles, tenant restrictions, and resource ownership;
7. reject malformed, duplicated, or unexpected claims;
8. avoid trusting client-supplied identity headers.

JWTs are often self-contained and can remain valid until expiry. This creates a revocation challenge. Short lifetimes, refresh-token protection, key rotation, token introspection, deny lists for exceptional cases, and central session controls can reduce the risk. JWTs should not be treated as a replacement for authorization policy.

7. Mutual TLS and Service-to-Service Security

Ordinary TLS authenticates the server to the client and encrypts the channel. Mutual TLS (mTLS) authenticates both endpoints using certificates. It is useful for service-to-service communication because a service can verify the calling workload before accepting a connection.

A sound mTLS design requires certificate issuance, private-key protection, rotation, revocation or short lifetimes, trust-anchor management, and clear identity-to-policy mapping. A service mesh may automate these functions, but automation does not remove the need to define authorization policy.

mTLS provides channel and workload authentication; it does not decide whether a particular operation is allowed. A correctly authenticated inventory service may still be forbidden from deleting products. Application-layer authorization and, where appropriate, end-user identity propagation remain necessary.

8. API Security

API security begins with explicit contracts and secure defaults.

Authentication and Authorization

Every protected endpoint should define its authentication mechanism and authorization rule. Authorization should be enforced at the service that owns the resource, not only at an edge gateway. Gateways are valuable for common controls, but downstream services must not assume that a gateway always performed correct authorization.

Object-level authorization is especially important. An endpoint such as /orders/123 must verify that the caller may access order 123, not merely that the caller has a general orders.read scope. This prevents insecure direct object references and cross-tenant access.

Input, Output, and Protocol Controls

Use strict schema validation, bounded input sizes, safe parsing, content-type checks, and output filtering. Protect against injection, server-side request forgery, deserialization attacks, path traversal, and unsafe file handling. Avoid returning internal stack traces or unnecessary personal data.

Rate limits and quotas should be designed by identity, tenant, endpoint, and resource cost. They help reduce abuse but do not replace authentication or authorization. Timeouts, bounded retries, circuit breakers, and payload limits also contribute to availability security.

Messages and Events

Asynchronous systems require equivalent controls. Producers and consumers need identities and authorization. Messages should include correlation identifiers without exposing secrets, and consumers should validate message schemas, origin, freshness, and authorization context. Replay protection may require unique message identifiers, timestamps, sequence numbers, or idempotency keys.

9. Secrets and Cryptographic Key Management

Secrets include passwords, API keys, private keys, database credentials, signing keys, and encryption keys. They should not be committed to source control, embedded in container images, placed in unprotected configuration files, or printed in logs.

A secrets-management system should provide controlled storage, access policies, auditing, versioning, rotation, and preferably short-lived dynamic credentials. Applications should retrieve secrets through workload identity, use them only when needed, and avoid copying them into broad process environments or diagnostic output.

Cryptographic keys require stronger lifecycle management than ordinary configuration. Important practices include generation using approved randomness, separation of duties, key rotation, restricted export, backup protection, compromise procedures, and algorithm governance. Encryption at rest is valuable, but key access must be controlled separately from data access.

10. Software Supply-Chain Security

Microservices depend on operating-system packages, language libraries, base images, build plugins, infrastructure modules, and external services. A vulnerability or malicious modification anywhere in this chain can compromise production.

Controls include:

• dependency pinning and reproducible builds;
• software composition analysis and vulnerability triage;
• signed commits, artifacts, and container images;
• software bills of materials (SBOMs);
• protected branches and reviewed changes;
• isolated and ephemeral CI runners;
• minimal base images and non-root containers;
• admission policies that reject unapproved images;
• provenance records showing how an artifact was built;
• rapid patching and dependency ownership.

Vulnerability scanners produce findings, not automatic risk decisions. Teams should consider exploitability, exposure, compensating controls, affected functionality, and remediation time. A high-severity library in an unreachable development component may require different action from a moderate flaw in an internet-facing parser.

11. Privacy Engineering

Security protects systems and information from unauthorized actions; privacy governs how information about people is collected, used, shared, retained, and explained. A system can be secure yet violate privacy by collecting excessive data or using it for an unexpected purpose.

Privacy engineering principles include:

• Data minimization: collect only what is necessary.
• Purpose limitation: use data for declared and legitimate purposes.
• Storage limitation: establish retention and deletion schedules.
• Transparency: explain processing in understandable language.
• User control: support access, correction, portability, objection, or deletion where applicable.
• Privacy by default: choose the least intrusive setting without requiring user action.
• Pseudonymization: separate direct identifiers from operational data where feasible.
• Aggregation: use less granular data for analytics when possible.
• Separation: isolate tenants, environments, and processing purposes.

Microservices complicate deletion and retention because copies may exist in caches, replicas, event logs, backups, data warehouses, and downstream systems. Privacy architecture should define data lineage and deletion semantics before deployment. Events should avoid unnecessary personal data; if an identifier is required, a stable pseudonymous identifier may reduce exposure, but pseudonymization is not equivalent to anonymization when re-identification remains possible.

Logs and traces deserve special attention. They should support accountability without becoming an uncontrolled copy of production data. Redaction, field allow-lists, access controls, retention limits, and monitoring of log access are essential.

12. Compliance and Governance

Compliance obligations vary by jurisdiction, industry, and data type. Relevant frameworks may address personal data protection, payment information, health information, financial controls, or organizational security management. Compliance is not identical to security: passing an audit does not prove that a system is safe, and a strong security control may still require documented evidence and defined governance.

A practical governance program should define:

• data classification and ownership;
• risk assessment and treatment;
• access reviews and segregation of duties;
• vulnerability and patch management;
• incident response and breach notification procedures;
• vendor and third-party assessment;
• retention and deletion rules;
• change management;
• evidence collection and audit trails;
• disaster recovery and business continuity.

Security and privacy requirements should be mapped to architecture decisions and tests. Teams should know which service is the system of record, which parties may access data, where data is processed, and how an incident will be detected and reported.

13. Illustrative Case: SecurePay Services

Background

SecurePay is an illustrative online retail platform composed of identity, catalog, cart, order, payment, notification, and analytics services. It uses a web client, a mobile client, a message broker, Kubernetes, and several external payment providers.

Problem

The first version relied on a perimeter gateway and a shared API key. Internal services trusted requests from the cluster network. JWT validation was inconsistent, logs included authorization headers, and the analytics pipeline retained full customer addresses indefinitely. A compromised catalog service could reach the order database because service accounts were broadly privileged.

Analysis

Threat modeling identified four high-priority risks:

1. A stolen token could be replayed against multiple APIs.
2. A compromised internal service could move laterally into payment and order systems.
3. Shared credentials prevented reliable attribution and rapid revocation.
4. Excessive retention and logging created privacy and breach-impact risks.

Approach

SecurePay adopted the following architecture:

• OIDC Authorization Code with PKCE for browser and mobile sign-in.
• Short-lived access tokens with service-specific audiences and narrowly defined scopes.
• Independent JWT validation at each resource server.
• Workload identities and mTLS for service-to-service communication.
• Separate service accounts for catalog, orders, payments, and analytics.
• Database permissions limited by service and operation.
• Network policies restricting which workloads may communicate.
• A secrets manager with automated rotation and audited access.
• Signed container images, SBOM generation, dependency scanning, and protected CI pipelines.
• Redaction of tokens and payment data from logs.
• Tokenized payment references rather than raw payment-card data.
• Retention schedules for events, logs, analytics, and backups.
• Centralized detection for unusual access, failed validation, and privilege changes.

The payment service still performed its own business authorization. A valid token with orders.read could not submit a payment, and an order identifier was checked against the authenticated customer or permitted support role.

Outcome

The revised design reduced the blast radius of a compromised catalog service, improved incident attribution, and made token misuse easier to detect. It did not eliminate risk. The organization still needed key rotation exercises, dependency updates, privacy reviews, penetration testing, and recovery drills.

Learning Points

The case demonstrates that security is layered. Gateway authentication, mTLS, JWT validation, application authorization, database permissions, supply-chain controls, and privacy safeguards solve different problems. None is a substitute for the others.

14. Challenges, Trade-offs, and Contemporary Practice

Security controls can introduce operational cost and failure modes. Short token lifetimes reduce replay windows but increase dependence on reliable token acquisition. Centralized identity improves consistency but creates an important availability dependency. mTLS improves workload authentication but requires certificate operations and careful debugging. Detailed logs support investigation but increase privacy and storage obligations.

Service meshes can automate encryption, identity, and traffic policy, but they do not automatically understand business authorization or data purpose. Policy-as-code improves reviewability and consistency, yet poorly designed policies can distribute errors at scale. Automated security testing is valuable, but tests must include tenant isolation, negative authorization cases, token substitution, replay, and failure behavior rather than only successful requests.

Artificial intelligence may assist vulnerability triage, anomaly detection, code review, and security operations. However, AI-generated code and configurations require human review. AI systems also create privacy, prompt-injection, data leakage, model supply-chain, and accountability concerns. Sensitive data should not be sent to an AI service without an approved purpose, contract, and technical safeguards.

Best-Practice Checklist

• Model threats before implementation and after significant changes.
• Use centralized identity standards but enforce authorization locally.
• Prefer short-lived, narrowly scoped credentials.
• Validate token issuer, audience, signature, time claims, and permissions.
• Use mTLS or an equivalent workload identity mechanism for internal calls.
• Treat network location as insufficient evidence of trust.
• Separate service identities and databases by responsibility.
• Store secrets in a managed system and rotate them.
• Secure source, dependencies, build systems, images, and deployment policies.
• Minimize personal data in APIs, events, logs, and traces.
• Define retention, deletion, incident response, and audit requirements.
• Test denial cases, cross-tenant access, replay, compromise, and recovery.

Chapter Summary

Secure microservices require a defense-in-depth architecture rather than a single security gateway. Threat modeling identifies assets, actors, trust boundaries, data flows, and plausible attacks. Zero Trust makes access decisions explicit and continuously evaluated, while least privilege limits the consequences of compromise.

Identity and access management distinguishes identity, authentication, authorization, and accountability. OAuth 2.0 supports delegated authorization, OIDC adds federated identity, JWTs carry verifiable claims, and mTLS authenticates service endpoints. Each technology has limitations and must be combined with resource-level authorization, secure key management, and monitoring.

API security requires strict validation, tenant-aware authorization, rate controls, safe error handling, and protection for asynchronous messages. Supply-chain security extends from source code through dependencies, builds, images, and deployment. Secrets require controlled storage and rotation. Privacy engineering minimizes collection, use, retention, and exposure of personal data. Compliance adds governance, evidence, accountability, and regulatory requirements. The central professional principle is to design for compromise: verify explicitly, restrict authority, protect data, observe behavior, and recover effectively.

Key Terms

Identity: A representation of a person, service, device, or workload.

Authentication: Verification of an entity’s claimed identity.

Authorization: Determination of what an authenticated entity may do.

Zero Trust: A security model that continuously verifies requests and does not grant implicit trust based on network location.

Least privilege: Granting only the permissions necessary for a task, resource, and duration.

Threat modeling: Structured analysis of assets, actors, threats, risks, and mitigations.

OAuth 2.0: A framework for delegated authorization using access tokens.

OpenID Connect: An identity layer built on OAuth 2.0.

Access token: A credential presented to a resource server to request authorized access.

JWT: A signed or encrypted token format containing claims.

Scope: A permission expressed in an access token.

Audience: The intended resource or API for a token.

mTLS: Mutual TLS, in which both communication endpoints authenticate with certificates.

Workload identity: An identity assigned to a running service, job, or process.

Secrets manager: A controlled system for storing, retrieving, rotating, and auditing secrets.

SBOM: Software bill of materials listing components in a software artifact.

Pseudonymization: Replacing identifying values with substitutes while retaining a possible re-identification path.

Data minimization: Collecting and processing no more personal data than necessary.

Blast radius: The extent of damage possible after a component or credential is compromised.

Review Questions

Short Answer Questions

1. Why is network location insufficient as a basis for trust in a microservices system?
2. What is the difference between OAuth 2.0 and OpenID Connect?
3. Why does a signed JWT not normally provide confidentiality?
4. State two advantages of separate workload identities.
5. What is data minimization, and why is it important for service logs?

Long Answer Questions

1. Explain a threat-modeling process for a microservices application, including assets, actors, trust boundaries, threats, and verification.
2. Compare human authentication, workload authentication, and application authorization in a Zero Trust architecture.
3. Describe how OAuth 2.0, OIDC, JWT validation, and resource-level authorization should work together in a web application.
4. Discuss the principal supply-chain risks in containerized microservices and propose layered controls.
5. Explain why privacy engineering must address event streams, caches, logs, backups, and analytics rather than only primary databases.

Analytical / Application Questions

1. A catalog service has a valid token with catalog.read but attempts to call the payment API. Identify the controls that should prevent this request and explain where each should be enforced.
2. Design a least-privilege policy for an order service that must create orders, read product availability, and publish order events but must not read customer passwords or payment-card data.
3. A company discovers that authorization headers and full customer addresses have been retained in logs for two years. Analyze the security and privacy risks and propose an incident, remediation, retention, and governance response.

Multiple Choice Questions with Answers

Question 1

Which statement best describes Zero Trust in a microservices architecture?

A. All traffic inside the cluster is trusted by default.

B. Access is explicitly verified and limited according to identity, context, and policy.

C. Only external users require authentication.

D. A perimeter firewall replaces service-level authorization.

Correct Answer: B. Access is explicitly verified and limited according to identity, context, and policy.

Question 2

What additional capability does OpenID Connect provide on top of OAuth 2.0?

A. Database encryption

B. Container signing

C. A standardized identity layer and ID token

D. Automatic mTLS certificate rotation

Correct Answer: C. A standardized identity layer and ID token

Question 3

Which JWT claim identifies the API for which a token is intended?

A. sub

B. aud

C. iat

D. jti

Correct Answer: B. aud

Question 4

Why should a resource server validate a token’s audience?

A. To determine the user’s password strength

B. To ensure the token was intended for that API

C. To encrypt the token payload

D. To establish database replication

Correct Answer: B. To ensure the token was intended for that API

Question 5

What does mutual TLS primarily provide for service-to-service communication?

A. Business-level authorization for every operation

B. Authentication of both endpoints and encrypted communication

C. Automatic deletion of personal data

D. Protection against all compromised dependencies

Correct Answer: B. Authentication of both endpoints and encrypted communication

Question 6

Which practice best demonstrates least privilege?

A. Giving every service administrator access to all databases

B. Using one shared API key for the entire platform

C. Giving a reporting service read-only access to only its required dataset

D. Allowing services to request unrestricted permissions at runtime

Correct Answer: C. Giving a reporting service read-only access to only its required dataset

Question 7

Which statement about an ordinary signed JWT is correct?

A. Its payload is always confidential.

B. It cannot expire.

C. Its signature can provide integrity, but the payload is generally readable.

D. It automatically revokes itself when a user changes a password.

Correct Answer: C. Its signature can provide integrity, but the payload is generally readable.

Question 8

Which control most directly addresses malicious or vulnerable third-party components?

A. Software bills of materials and dependency scanning

B. Increasing API response size

C. Disabling all audit logs

D. Using a shared production password

Correct Answer: A. Software bills of materials and dependency scanning

Question 9

Which example best represents privacy by design?

A. Retaining full addresses in all logs indefinitely

B. Collecting only the data necessary for the stated service purpose

C. Copying production data into every test environment

D. Allowing all analysts to view raw identifiers

Correct Answer: B. Collecting only the data necessary for the stated service purpose

Question 10

A gateway authenticates a caller, but the order service returns any order when given its identifier. What vulnerability is most directly present?

A. Insufficient object-level authorization

B. Certificate pinning

C. Dependency lockfile protection

D. Data compression failure

Correct Answer: A. Insufficient object-level authorization