Chapter 4: Governance, compliance, and trust

Introduction

The introduction argues that platform engineering must change how organizations handle governance and compliance without taking control of CI/CD pipelines away from developers.

• Organizational sources of friction: Explain why buying a tool or funding a one-time project is unlikely to resolve governance and compliance friction in platform engineering.
  Why it matters: A platform cannot remove friction if the organization preserves the decisions and incentives that create it.
• Compliance responsibilities and roadblocks: Describe why necessary compliance requirements should not simply become implementation tasks assigned to stakeholder teams.
  Why it matters: The goal is to meet real requirements without recreating the obstacles developers already face.
• Developer control of pipelines: Explain why the introduction favors development teams retaining functional control of CI/CD pipelines rather than treating them as centralized compliance gates.
  Why it matters: Who controls pipelines affects both developers’ ability to build quality into delivery and the friction they encounter.

Key terms: governance, compliance, engineering friction, audit, security, platform engineering standards, CI/CD pipelines, developer autonomy, command and control gate

4.1 Developer autonomy

The section explains why developer autonomy should vary with experience while remaining within a structure that supports governance.

• Skill-dependent value of checklists: Explain why a checklist can improve a novice’s performance but hinder an expert’s, using the pilot study or the section’s examples.
  Why it matters: The same control can help someone learning a task and slow down someone who has mastered it.
• Structured developer autonomy: Describe how a platform can support novice developers and give experienced developers room to make decisions without abandoning governance.
  Why it matters: A platform can remove needless delays for experienced developers while still helping newcomers and maintaining controls.

Key terms: Dreyfus Skill Model, novices, experts, intuition, checklists, developer autonomy, starter kits, governance, centralized pipeline team, build and release pipelines

4.1.1 What does it mean to make a development team autonomous?

The section explains how development teams can control their own pipelines while the platform verifies compliance when changes reach an environment.

• Developer control with guardrails: Explain why development teams should retain control of their pipelines and how separating compliance work from verification reduces friction without removing guardrails.
  Why it matters: This distinction is what makes developer autonomy compatible with compliance.
• Verification at the point of change: Describe when compliance verification occurs and how a Kubernetes admission controller can intercept a deployment before it proceeds.
  Why it matters: Checking at deployment keeps verification close to the change without dictating how developers organize their pipelines.
• Evidence checks and configuration checks: Distinguish verifying evidence that compliance work was done from directly checking a deployment’s configuration, using the scan-record and label examples.
  Why it matters: The two examples show what a deployment guardrail actually verifies—and what it does not need to redo.
• Reusable compliance work in pipelines: Explain how reusable, versioned pipeline code lets teams perform required compliance work while keeping their choice of pipeline.
  Why it matters: A shared way to do the work makes the guardrail practical without imposing one team-owned pipeline.
• Other settings and checking times: Describe how the point-of-change strategy can extend beyond Kubernetes and how immediate post-change scans differ from prechecks.
  Why it matters: The autonomy principle does not depend on a single control plane or on blocking every change in advance.

Key terms: developer autonomy, guardrails, compliance work, compliance verification, point of change, all the way left, admission controller, validating webhooks, authoritative source, image commit SHA

4.2 Policy-as-code

This section explains why a platform needs a policy engine to enforce shared requirements without taking ownership of development teams’ pipelines, and introduces Open Policy Agent as one option.

• Policy enforcement with team ownership: Explain how a platform can enforce an organization-wide requirement while development teams retain ownership of their pipelines, using the test-coverage example.
  Why it matters: Shared rules can be enforced without taking control of teams’ delivery pipelines.
• Open Policy Agent option: Describe Open Policy Agent’s role as a policy-engine option and identify Rego as the language used to interact with it.
  Why it matters: It identifies the policy engine used in the book’s examples without implying it is the only choice.

Key terms: policy-as-code, compliance at the point of change, admission controllers, policy engine, Open Policy Agent, OPA, Rego, declarative policy engine

4.2.1 Introduction to policy-as-code using Open Policy Agent

This section introduces how OPA evaluates Rego policies, then applies that model to site access and Kubernetes deployment decisions.

• OPA policy evaluation model: Explain how Open Policy Agent uses data and Rego requirements to make a policy decision, and how it can enforce governance requirements as a Kubernetes admission controller.
  Why it matters: This is the basic model behind the section’s access and deployment examples.
• Predicates and data domains: Describe how a Rego assertion expresses an approved condition, and explain the section’s distinction between a predicate, a subject variable, and the domain of possible subjects.
  Why it matters: Predicates and domains explain why the same stated requirement can evaluate differently for different data.
• Age-based access decision: Trace the site-access example from its age requirement and user data to the different decisions for Ling and Ama.
  Why it matters: The age example shows how an assertion turns a stated requirement into a concrete access decision.
• Deployment coverage policy: Trace how the Kubernetes deployment example uses admission-time input and code-coverage data to enforce the 80% requirement, and state the additional deployment requirements posed in the exercise.
  Why it matters: This example connects policy evaluation to a deployment decision using evidence from an external reporting tool.

Key terms: Open Policy Agent, OPA agent, admission controller, Rego, JSON, declarative, assertion, predicate, subject variable, data domain

4.3 Platform-managed trust

The section frames an engineering platform as a way to establish and maintain trust in custom software, while previewing trust topics covered next.

• Platform support for digital trust: Explain the section’s claim that using an engineering platform to support custom software development is the most efficient way to build and maintain trust.
  Why it matters: This claim provides the trust rationale for the platform practices discussed next.

Key terms: engineering platform, trust, custom software

4.3.1 Software supply chain security

This section explains how an engineering platform can establish software provenance and enforce supply chain security from commit to deployment without relying on manual checks.

• Supply chain attack risk: Explain how a compromised build process can make malicious software appear trustworthy and why preventing such attacks matters.
  Why it matters: A trusted-looking release is not enough if the process that produced it has been compromised.
• Commit-to-deployment provenance: Describe the identity, audit, and artifact-integrity measures the section proposes for tracing software from development to deployment.
  Why it matters: These measures provide evidence of who changed the code, what the pipeline accessed, and what went into the deployed image.
• Automated supply chain enforcement: Explain how the platform can provide supply chain safeguards without manual friction and how it can check requirements before deployment.
  Why it matters: Platform-provided automation makes the secure path easier for development teams while retaining checks before deployment.

Key terms: software supply chain security, software provenance, CI/CD process, signed commits, content trust, signed images, software bill of materials (SBOM), software-defined, reusable pipeline code, point-of-change compliance

4.3.2 Zero-trust networking

This section explains how to apply zero-trust networking to platform services and weigh service-mesh controls against network-level policies and self-managed pod networking.

• Zero-trust security assessment: Explain why zero-trust networking does not treat presence on an internal network as proof that a system is secure, and what follows for assessing individual systems.
  Why it matters: A service should remain secure even when the network around it changes.
• Service-mesh authorization with OPA: Trace how the section's service-mesh and OPA approach can restrict calls to an API to authorized applications.
  Why it matters: The platform can offer a common authorization path without making every service team solve general access controls alone.
• Default-deny service access: Describe how the service-mesh example blocks unregistered destinations and permits a specifically approved service.
  Why it matters: A default-deny rule makes permitted destinations explicit rather than allowing every destination unless someone blocks it.
• Pod-network architecture tradeoffs: Justify why the section favors a portable, dedicated service mesh over taking on a self-managed pod network solely for its policy features.
  Why it matters: The policy technology chosen also affects security-assessment boundaries, operating costs, and portability.
• Evidence for network self-management: State what evidence the section calls for before self-managing a pod or service network for performance, and how it qualifies its eBPF recommendation.
  Why it matters: Measured customer impact is a stronger reason to accept networking complexity than a presumed performance gain.

Key terms: zero-trust networking, threat assessment, network settings, service mesh, OPA, policy-as-code, service mesh proxy, web tokens, default deny, ServiceEntry

4.3.3 Separating platform customer identity from cloud infrastructure identity

This section explains how a team-centered customer identity and integration architecture can give developers consistent access without tying their identities to cloud infrastructure accounts.

• Fragmented developer access: Explain why obtaining access to developer tools and infrastructure is often slow, and why centralizing access to SaaS tools alone does not solve the whole problem.
  Why it matters: A self-serve platform experience has to cover the resources developers actually need, not just the easiest tools to integrate.
• Team-centered authorization model: Distinguish individual authentication from team-centered authorization and describe what team membership should grant by default.
  Why it matters: A consistent team boundary makes access easier to provide and maintain as teams and platform resources change.
• Intermediary identity and claims: Describe the identity provider’s intermediary role and how authorization claims reach services through OIDC token issuance.
  Why it matters: Claims let the same customer identity support control-plane access and custom platform integrations without making each underlying system the identity authority.
• Platform-managed infrastructure access: Explain how team claims apply to control-plane permissions and why the platform provisions infrastructure on users’ behalf.
  Why it matters: This preserves a product-like developer experience while keeping the platform responsible for how infrastructure is created and managed.
• Event-driven team integration: Trace how a Teams API and integration APIs keep a newly onboarded team’s resources and permissions aligned across systems.
  Why it matters: Team onboarding can become one coordinated action even when different departments continue to administer the underlying systems.

Key terms: developer onboarding, time to first production deployment, self-serve, authentication, authorization, team member, team membership, identity provider, OpenID Connect, authorization server

4.4 Summary