Golden Paths: Platform Engineering with Secure Defaults
Self-service infrastructure only works when the default option is the secure option. How to design golden paths that developers actually want to use.
Platform engineering promises self-service infrastructure without chaos. The mechanism is the golden path — a blessed, supported way to build and deploy software. But a golden path that developers bypass is just documentation nobody reads.
What makes a path golden
A golden path is not a template repo collecting dust. It is an opinionated, automated workflow that is genuinely the fastest way to ship:
- Faster than the alternative — if the workaround is quicker, developers will use it
- Secure by default — network policies, RBAC, and scanning are baked in, not bolted on
- Observable from day one — metrics, logs, and traces pre-configured
- Supported — a team stands behind it with SLAs, not "best effort" Slack responses
The platform contract
Define what the platform team guarantees versus what product teams own:
| Platform provides | Team owns |
|---|---|
| Kubernetes cluster management | Application code |
| CI/CD pipeline templates | Business logic tests |
| Secret management integration | Secret rotation requests |
| Network policy baselines | Service-specific rules (within guardrails) |
| Monitoring dashboards (infra) | Custom application metrics |
This contract prevents the platform team from becoming a bottleneck while keeping security boundaries clear.
Policy-as-code in practice
Golden paths enforce policy through automation, not review gates. Example flow:
- Developer selects a service template in the internal portal
- Backstage (or similar) provisions repo, CI pipeline, and namespace
- OPA/Gatekeeper policies auto-applied: no privileged containers, required labels, network segmentation
- First deploy succeeds because the path was designed to pass all policies
# Deny deployments missing required security context
deny[msg] {
input.request.kind.kind == "Deployment"
not input.request.object.spec.template.spec.securityContext.runAsNonRoot
msg := "Deployments must set runAsNonRoot in pod securityContext"
}
Developers never see the policy — they see a template that already complies.
Measuring golden path adoption
Track these metrics to know if your platform is working:
- Template usage rate — percentage of new services created via golden path vs. manual
- Time to first deploy — how long from repo creation to running in staging
- Policy exception rate — frequent exceptions signal a path that does not fit real needs
- Developer satisfaction — quarterly survey, not anecdotal Slack praise
A golden path with 30% adoption is a failed path. Investigate why developers avoid it.
Security without friction
The most common mistake is adding security steps that slow developers down without explaining the value. Instead:
- Auto-scan containers in the pipeline and surface results in the PR — not a separate security ticket
- Pre-configure mTLS between services in the mesh — developers do not configure certificates manually
- Embed SAST/DAST in the golden path CI template — failures include remediation guidance, not just CVE IDs
Security becomes invisible infrastructure, not a gate at the end.
Getting started
Pick one service type (e.g., REST API) and build a single golden path end to end. Measure adoption for a quarter before expanding to other patterns.
We design platform engineering programs with security embedded in every template and policy. Let's talk about your internal developer platform.