Platform Engineering Security: Secure Golden Paths

An internal developer platform concentrates the power to create infrastructure, deploy code and issue credentials for the whole organisation into one system and one team, so it can either make every team secure by default or become the single place an attacker needs to compromise. Platform engineering treats infrastructure and delivery tooling as a product for developers: golden paths, templates, self-service APIs and portals. Security teams that engage early can build controls into those paths so that the easy way is also the safe way. This guide covers the platform as a product, golden paths with security baked in, the identity model of self-service infrastructure, policy as code guardrails, secrets and workload identity, and the privilege and blast radius of the platform team itself. It is for platform engineers, DevSecOps leads and security architects. Portal-specific hardening for one popular tool is in the Backstage Developer Portal Security Guide.

Key takeaways

The golden path is the strongest security control you have. If the template, pipeline and runtime defaults are secure, every new service starts compliant without a review queue.
Self-service needs an identity model, not just an API. Every self-service action must run as a scoped, auditable identity tied to the requesting team, never as one all-powerful platform account.
Guardrails belong in code and run in audit mode first. Policy as code at the pipeline, admission and cloud organisation layers enforces rules consistently, and audit mode shows the impact before anything is blocked.
Workload identity replaces distributed secrets. The platform should issue short-lived, attested identities to workloads so teams never handle long-lived keys.
The platform team is a privileged team. Its people, pipelines and controllers can change everything, so treat them like domain administrators: least privilege, just-in-time access and strong monitoring.

Platform as a product, and why security changes

The CNCF Platforms White Paper describes a platform as an integrated collection of capabilities shaped by its users' needs, offered through consistent interfaces such as web portals, project templates and self-service APIs. It lists the attributes of a good platform: platform as a product, user experience, self-service, reduced cognitive load, optional and composable, and secure by default, which it describes as building in compliance and validation based on organisational rules and standards. Among its capability domains are identity and secret management (service and user identity and authorisation, certificate and key issuance, secret storage) and security (static and runtime analysis, artefact verification and policy enforcement).

Security changes in three ways when a platform exists:

From review to design: instead of reviewing each team's infrastructure, security reviews the template once and every consumer inherits the result.
From many small risks to one large one: the platform's control plane, credentials and pipelines become a concentrated, high-value target.
From policy documents to enforced defaults: rules are expressed as code in the paths developers use, which makes them testable and measurable.

The "optional and composable" attribute matters for security too. Teams that leave the golden path need clear minimum guardrails that still apply to them; otherwise the platform becomes the secure option only for teams that choose it.

Golden paths with security baked in

The CNCF paper describes a golden path as a reusable bundle for a common workflow, such as building, scanning, testing, deploying and observing a web application on Kubernetes, typically with a project template and documentation, and notes that governance and controls can be embedded in templates and patterns. A secure golden path should contain the following by default.

Layer	Secure default in the golden path	What it prevents
Repository	Branch protection, required review, CODEOWNERS, secret scanning and dependency updates enabled at creation	Unreviewed changes, committed secrets, stale dependencies
Build	Hosted build platform, pinned base images, SBOM generation, signed provenance	Tampered builds, unknown components (SLSA Build L2 and L3 aims)
Testing	Static analysis, dependency and container scanning with agreed severity gates	Known vulnerabilities reaching production
Deployment	Pipeline deploys signed artefacts only, via federated short-lived credentials, with approvals for production	Manual deployments, stored deploy keys, unsigned images
Runtime	Non-root containers, restricted Pod Security Standard, network policies default deny, resource limits	Container escape paths, lateral movement
Identity	Workload identity bound to the service, scoped roles generated from the template	Shared or long-lived credentials
Observability	Structured logs, audit events and alerts wired to the central platform	Blind spots after deployment

Version the templates: golden paths drift. Track which services were created from which template version, and give teams an automated upgrade path when a security default changes.
Secure the template engine: scaffolders that create repositories and cloud resources run with powerful tokens. Scope those tokens to the actions the templates perform and log every run.
Build provenance: SLSA v1.0 defines Build L1 (provenance exists), Build L2 (hosted build platform with signed provenance) and Build L3 (hardened builds that isolate runs and keep signing secrets away from user-defined steps). L2 is a realistic default for a platform; L3 is the target for critical services. See the SLSA and Build Provenance Guide and the Sigstore Guide.

Self-service infrastructure and its identity model

Self-service is the point of a platform, and its identity model decides whether self-service is safe. Three designs are common.

Design	How it works	Risk	Verdict
Single platform super-identity	The portal or controller holds one credential with admin rights everywhere and acts on behalf of all users	One stolen token compromises every account; audit logs show only the platform, not the requester	Avoid
Per-team delegated identities	Each team or workload has its own scoped role; the platform assumes it for that team's requests	Mistakes in mapping teams to roles	Good default
User-delegated actions	The platform acts with the requesting user's own token or a token exchanged for it	Users may hold more rights than the action needs	Good for audit; combine with scoped roles

Bind requests to people: every self-service action records who asked, which team owns the result and which identity performed it, so cloud audit logs can be traced back to a human request.
Scope by account or project: provision each team's resources into its own accounts or projects, with the platform's role in that account limited to what the templates create. See the Environment Separation.
Use the portal's authorisation, not only its login: developer portals often authenticate everyone via SSO but authorise every action by default; enable and configure their permission frameworks.
Treat controllers as identities: infrastructure controllers and GitOps agents reconcile resources continuously with standing credentials. Inventory them as non-human identities with owners. See the GitOps Security Guide.

Ephemeral and preview environments

Many platforms let a pull request spin up a short-lived preview environment. These are useful and risky: they are created by automation on untrusted code, often reachable from the internet, and easily forgotten. Give preview environments their own accounts or namespaces with no access to production data or production secrets, put authentication in front of any public URL, apply the same admission policies as other environments, and set an automatic time to live so they are destroyed when the pull request closes. Pull requests from forks should never receive credentials that can create cloud resources. Track the count and age of live preview environments as a hygiene metric.

Policy as code guardrails

Guardrails are rules the platform enforces automatically. They should exist at more than one layer, so a gap in one is caught by another.

Layer	Examples	Typical tooling
Pipeline (pre-deploy)	Infrastructure as code checks for public storage, open security groups, missing encryption, over-broad IAM	IaC scanners, OPA-based checks
Kubernetes admission	Reject privileged pods, unsigned images, images from unapproved registries, missing labels	Pod Security Admission, Kyverno, OPA Gatekeeper
Cloud organisation	Deny unapproved regions, deny disabling audit logs, require encryption, block public access	AWS service control policies, Azure Policy, Google organization policies
Runtime detection	Unexpected processes, shells in containers, privilege escalation	Falco and similar runtime tools

Rollout with audit first:

Start in audit mode: Kubernetes Pod Security Admission supports enforce, audit and warn modes per namespace through pod-security.kubernetes.io/<mode> labels; set audit and warn to restricted first to find violations. Kyverno's failureAction field takes Audit, which records violations in PolicyReport resources, or Enforce, which blocks the request (the older validationFailureAction field is deprecated).
Publish the results to teams: show each team its violations in the portal with a fix, usually a template upgrade.
Enforce for new resources: switch to enforce for new namespaces and services first, leaving existing violations to be fixed on a schedule.
Enforce everywhere with exceptions: exceptions are time-limited, approved, recorded in code and reviewed.
Roll back cleanly: because policies are code in version control, reverting a policy that breaks production is a normal change, not an emergency edit.

See the Kubernetes Admission Control Guide and the Policy-as-Code for Authorisation Guide.

Secrets and workload identity

A platform should mean developers almost never handle a secret. The CNCF paper lists SPIFFE/SPIRE and cert-manager as example projects for identity and certificate issuance. SPIFFE defines short-lived identity documents (SVIDs) in X.509 and JWT forms, issued to workloads through a Workload API that supports automatic rotation; SPIRE is its open-source implementation.

Cloud access: use the cloud provider's workload identity (IAM roles for service accounts, managed identities, workload identity federation) issued per service by the template. See the Cloud Workload Identity Guide.
Service-to-service: mutual TLS with platform-issued certificates, or SPIFFE identities, instead of shared API keys.
Pipelines: CI jobs federate to the cloud with OIDC tokens rather than stored keys. See the GitHub Actions OIDC Federation Hardening Guide.
Remaining secrets: third-party API keys that cannot be federated live in a central secrets manager, injected at runtime, with owners and rotation. See the Kubernetes Secrets Security Guide.

Platform team privilege and blast radius

The platform team typically holds cluster-admin on shared clusters, organisation-level cloud roles, write access to every template and the signing keys for artefacts. That is Tier 0 access.

No standing admin: platform engineers work through the same pipelines as everyone else; direct admin access is just-in-time, approved and recorded. See the JIT Access Guide.
Protect the platform's own supply chain: changes to templates, policies, base images and pipeline definitions need two-person review, because one malicious change propagates to every service.
Split the control plane: separate the identities that manage the platform from those that deploy workloads, and separate production platform components from non-production ones.
Harden engineers' endpoints: the LastPass Breach 2022 shows the pattern: one of only four DevOps engineers with access to backup decryption keys was compromised through their home computer, and the stolen AWS keys were then used to copy customer vault backups. Use managed devices and phishing-resistant MFA, and keep keys out of personal vaults. See the Privileged Access Workstations Guide.
Plan for platform compromise: document how to revoke platform credentials, freeze template changes and verify artefacts if the platform itself is breached. See the CI/CD Pipeline Compromise Playbook.

Decision guidance: a small organisation may not need a portal at all; the CNCF paper notes a very simple platform can be a wiki page of links to standard procedures. Start with secure repository and pipeline templates plus cloud organisation guardrails. Large organisations with many teams gain most from a full platform, but must invest in its identity model and the platform team's privilege controls before scaling self-service.

Detection and measurement

Log every self-service request, template run, policy change and platform admin session, and send cloud, Kubernetes and portal audit logs to the SIEM. Alert on platform credentials used outside the platform's own hosts, template or policy changes merged without review, admission policies switched from enforce to audit, and new cluster-admin bindings. Relevant ATT&CK techniques include T1078.004 Cloud Accounts, T1098 Account Manipulation, T1525 Implant Internal Image and T1610 Deploy Container. See the Kubernetes Audit Log Detection Guide.

Golden path adoption: percentage of services created from, and current with, a supported template version.
Policy coverage and enforcement: percentage of clusters and accounts with guardrails in enforce mode.
Open exceptions: number and age of policy exceptions past expiry (target zero).
Long-lived credentials: count of static keys issued to workloads, trending to zero.
Standing platform admin: number of people with permanent cluster-admin or organisation admin (target near zero).
Time to propagate a security default: days from a template fix to its adoption across services.

Framework mapping

Platform control	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ATT&CK addressed
Secure golden path templates	SA-8, CM-2, CM-6	PR.PS-01, PR.PS-06	T1610
Build provenance and signing	SR-4, SA-10	GV.SC-01	T1195.002, T1525
Policy as code guardrails	CM-3, CM-5	PR.PS-01	T1610
Workload identity and secrets	IA-5, IA-9, SC-12	PR.AA-01	T1078.004
Platform team privilege	AC-2, AC-6(5)	GV.RR-02	T1098
Platform audit logging	AU-12	DE.CM-09	T1609

Common failure patterns

One token to rule them all: the portal or scaffolder holds an organisation-wide admin token, so compromising the portal compromises every repository and account.
Templates that never update: services are created from a secure template once and then drift, so a new default never reaches existing services.
Guardrails switched off to unblock a release: admission or organisation policies flipped to audit "temporarily" and never switched back.
Paved road for some, gravel for others: teams off the golden path have no minimum guardrails at all.
Platform engineers with standing Tier 0 access from ordinary laptops: as in the LastPass Breach 2022, a small group with keys to everything is a single point of failure.
Secrets distributed instead of identities: the platform hands out long-lived API keys to teams because federation was not built, recreating the sprawl it was meant to remove.

Practitioner checklist

Define secure defaults for repository, build, deploy, runtime, identity and observability in every golden path template.
Version templates and track which services use which version, with an automated upgrade path.
Run self-service actions as per-team scoped identities tied to the requesting user, never one super-identity.
Enforce guardrails at pipeline, admission and cloud organisation layers, rolling out in audit mode first.
Issue workload identities and federated pipeline credentials by default; keep remaining secrets in a central manager.
Aim for SLSA Build L2 by default and L3 for critical services, with signed artefacts verified at admission.
Remove standing admin from the platform team; use JIT access and two-person review for templates and policies.
Set minimum guardrails that apply to teams off the golden path.
Log and alert on platform credential use, policy changes and admin sessions; report the six metrics monthly.

Platform Engineering Security: Build Golden Paths With Guardrails Built In