4 Governance, Compliance, and Trust

This chapter argues that effective platform engineering requires rethinking governance, compliance, and internal trust—rather than layering new tools onto old structures. Traditional centralized controls and ticket-driven processes create friction that undermines developer productivity and the promise of platform outcomes. The authors emphasize preserving developer autonomy (especially ownership of CI/CD pipelines) while meeting the needs of security, audit, and legal teams. They advocate changing operating patterns, not just tooling, so that controls are built into the platform experience in ways that scale, minimize handoffs, and respect expert workflows.

A core pattern is to separate “doing the work of compliance” from “verifying compliance,” shifting verification to the point of change (e.g., at deployment) via admission controls. Using policy-as-code—such as Open Policy Agent with Rego—lets teams encode requirements (like vulnerability scans tied to image SHAs, mandatory labels, or code coverage thresholds) as declarative checks that run automatically and consistently across environments. Developers retain pipeline control and use reusable, versioned components to meet requirements, while the platform verifies compliance pre- or post-change with minimal friction. Though Kubernetes makes this model natural with admission controllers, analogous approaches exist for other ecosystems and can be extended through proxies or policy engines to standardize verification everywhere.

The chapter extends these ideas to platform-managed trust: strengthening software supply chain security (signed commits, auditable pipelines, trusted registries, signed images, and SBOMs verified at deploy time), implementing zero-trust principles with service mesh and policy-as-code (favoring L7 authorization over fragile network-only controls), and modernizing identity. It recommends treating the team as the primary authorization unit, using a dedicated IDP that issues standards-based tokens with claims (e.g., OIDC/JWT), integrating those claims with control-plane access, and provisioning cloud resources on users’ behalf. Finally, it proposes an event-driven integration orchestrator that automates team onboarding and keeps configurations consistent across tools and environments—reducing onboarding time, improving compliance posture, and sustaining flexibility as the platform evolves.

The original table from Dreyfus and Dreyfus' paper (Dreyfus, Stuart E.; Dreyfus, Hubert L., A Five-Stage Model of the Mental Activities Involved in Directed Skill Acquisition, p. 19)

The all too common pipeline

Kubernetes Admission Controller

Admission controller built using Gatekeeper[1] that checks for labels on the deployment

Before completing a deployment request, the Kubernetes API will call any admission controllers that we have defined.

Software created by users of our platform follows a known path. Developers create code, the pipeline creates an executable version and stores it, and then the pipeline deploys the executable to the target environment. Depending on the type of application, end-users may get a copy to run themselves.

Steps along the way, from code creation to deployment, can automatically create the necessary provenance.

We want the IDP to be the go-between rather than the source of truth, and we will need to be able to customize the results from the authorization service.

The result is something that is already happening. The problem is that Developers are generally left on their own to figure out what these things are and then follow a manual process to get the result.

Our integration orchestrator will be the authoritative source for teams that have onboarded to the engineering platform. By adopting an event-driven architecture in which each of the specific integration or configuration resources responds to, we make it easy to shift and scale the responsible teams as well.

As long as there is a single, primary platform integration orchestrator modeled around the primary customer persona (“the team”) that maintains and populates this standard event stream, it is easy for these integration activities to evolve with our platform.

• Governance, compliance, security, and audit must be integrated into both the platform and development processes.
• A company's existing structures and decision-making habits are how it got to where it is now. To achieve something different is going to require change.
• Over-controlling approaches to governance and compliance lead to inferior results.
• We can create effective governance and compliance while still letting Developers be responsible for the things that make them effective and better at their jobs.
• Separate the work of becoming compliant from the task of verifying compliance.
• Verify compliance at the point where the change is about to occur.
• Compliance at the Point of Change decouples compliance work from its verification, enabling self-service deployments while maintaining security standards.
• A service that can validate or even change code right before the moment it is deployed is called an admission controller.
• The Kubernetes API includes support for admission controllers that can be used to enforce compliance at the deployment environment boundary.
• An admission controller enables governance, compliance, or security requirements to be verified before code is deployed without the need to control the development process itself.
• With so many different stakeholder disciplines making up governance requirements, it is effective to use a standard policy language to describe requirements.
• Open Policy Agent and the Rego policy language offer a widely used and broadly applicable example of a common policy-as-code implementation strategy.
• Rego and OPA are designed to enable ingesting data from any source to make policy decisions.
• An engineering platform can reduce the complexity involved in implementing modern Trust architectures.
• A built-in policy-as-code capability in a platform can be used to create enforcement gates for most trust concerns.
• Using a standardized control plane in a platform provides a mechanism for making zero-trust network controls portable.
• Trust around the platform user identity can be architected to create flexibility.
• Distinguishing between Platform Customer Identity and the default cloud infrastructure identity system helps manage access and responsibilities efficiently.
• Make the development team the central authorization role.
• Use a dedicated Identity Provider solution in your platform architecture.
• Adopt a common standard, like OpenID Connect, and apply it as broadly as possible.
• User access to infrastructure is through the control plane.
• Access to the control plane goes through the dedicated platform user IDP solution.
• Infrastructure available through the platform is provisioned by the platform on the development team's behalf rather than merely granting the team permissions to do it themselves.
• Decoupling customer identity from infrastructure is essential for managing access without overwhelming central teams.
• One of the first and central features of an engineering platform is in fully automating the development team (and individual developer) onboarding experience.
• Single Sign On features in Identity Provider solutions, when implemented well, are an essential part of creating the onboarding experience.
• But to effectively maintain platform customer “access” automation, we need to build our own integration orchestrator API(s) to deal with the integration details not managed by our SSO service.
• Building the integration API around an event stream makes the solution much easier to adopt throughout the enterprise.

FAQ