Foundation — Identity, Networking & Secrets

Foundation

[The Platform Engineering Journal — Chapter 003]

Executive Summary

Every enterprise platform inherits its ceiling from its foundation. Not its potential its ceiling.

Build a brilliant automation layer on a weak identity model, and the automation inherits the weakness. Build an elegant developer platform on a flat network, and the flatness travels upward with it. Build sophisticated observability on secrets stored in pipeline variables, and the observability just gives you a clear view of the breach after it happens.

Whatever the Foundation layer gets wrong, every layer above it inherits — usually silently, usually for years, usually until an incident forces the conversation that should have happened at design time.

This chapter names the framework I use to think about that first layer, walks through why each of its three pillars behaves the way it does across clouds, and follows a single deployment end-to-end to show the pillars working together rather than in isolation.

Introduction

In Chapter 2, I described Foundation as the layer that provides base infrastructure: networking, identity, secrets, logging. Accurate, and incomplete it made Foundation sound like plumbing, installed once and forgotten.

It isn't that.

Foundation is where every future security incident is either prevented or quietly scheduled. It's where the blast radius of a compromised credential gets decided months before that credential is ever compromised. It's where "who can deploy to production" stops being a policy document and starts being an enforceable fact.

I call the model underneath this chapter the Enterprise Trust Stack — three rings of trust, each depending on the one beneath it:

The Identity Ring answers who. The Network Ring answers how far. The Secrets Ring answers with what. A request that fails any one ring should fail closed, not open — and a platform that can't explain, for any given request, which ring granted it access, doesn't have a Trust Stack. It has three tools that happen to sit near each other.

I'll return to this framework throughout Part II. Platform Services, the Developer Platform, Governance, and Business all sit on top of whatever the Trust Stack decides is possible.

Most platform teams get infrastructure right. Fewer get the Trust Stack right, because infrastructure is about provisioning resources correctly, and the Trust Stack is about designing constraints correctly and constraints are much harder to retrofit than resources are.

They're also hard to write about honestly if you only describe one cloud. The platforms I've worked on span Azure, AWS, hybrid connectivity into on-premises data centres, and virtualization layers that predate any of it.

The Trust Stack looks different on the surface in each. Underneath, it's the same three rings, in a different accent.

The Identity Ring

For most of my career, "perimeter" meant network perimeter — firewalls, VPNs, a hard shell around a soft inner network. That model is dead. Fewer organisations have fully internalised what replaced it.

Identity is the perimeter now.

Every managed identity, every IAM role, every federated login is a door. A mature platform doesn't ask whether a request came from inside the network. It asks whether this specific identity has this specific permission, right now, for this specific action.

The mechanism differs by platform. The pattern doesn't:

Engineers new to multi-cloud work often treat "Azure identity" and "AWS identity" as separate disciplines. They're one discipline — short-lived, automatically rotated, workload-scoped credentials — wearing different vendor terminology.

Three decisions recur, regardless of cloud. Platform-managed identity over stored credentials, wherever allowed an identity the cloud provider rotates automatically removes an entire category of "how did this credential end up in a script" incidents before they can happen.

Federation over long-lived accounts, especially for CI/CD — a pipeline authenticating via OIDC has no secret to leak, rotate, or forget about, and GitHub Actions, GitLab CI/CD, and Azure DevOps all support this natively now.

And role assignments scoped to resource, not account: Contributor at the subscription level, or Administrator Access on the account, is almost never a decision made on purpose. It's a decision made under deadline pressure that nobody circled back to. It works and it means one compromised identity reaches everything.

That last pattern is the single most common finding in every cloud security posture review I've run. A read-only scan across an AWS account — IAM users without MFA, access keys unrotated past ninety days, Administrator Access attached directly to a user instead of a role, inline policies **granting * on *** surfaces the same shape of problem regardless of the organisation: a handful of identities with far more reach than any workload actually needs. Nobody decided that on purpose.

Nobody decided it at all, which is the worse root cause, because the fix isn't a conversation it's a process that was never built.

For the platform team, this means: identity can't be a ticket. If provisioning a scoped identity takes a request, an approval, and three days, engineers will keep reusing whatever identity already exists the shared one, the over-privileged one. Identity has to be templated and self-service, or the platform trains people to route around it within a month.

Zero Trust Isn't a Product

Zero Trust gets sold as something you buy a gateway, a proxy, an agent on every device. Vendors are happy to let that misunderstanding persist; it turns an architectural principle into a line item.

It's a posture, built on ideas that are easy to state and hard to implement. Verify explicitly: authenticate and authorise every request against all available signal — identity, device, location, workload — not against which network segment it arrived from. Least privilege: access scoped to exactly what's needed, for exactly as long as it's needed, with standing access as the exception rather than the default. Assume breach: design as though an attacker is already inside the perimeter, because eventually one will be. Continuous evaluation: trust granted at login shouldn't be honored unconditionally for the rest of a session conditional access re-evaluates risk throughout, and can revoke access mid-session.

Applied to a platform rather than an office network, this means three identities get evaluated on every request, not one: workload identity (which service is calling), device identity (for human access, is this a managed, compliant device), and network identity (even inside a private network, is this specific path expected, or merely possible).

This is the section that bridges the Identity Ring and the Network Ring. A private endpoint isn't a security control on its own it's one signal among several. Zero Trust stitches identity, device posture, and network path into a single access decision instead of three disconnected ones.

For the platform team, this means: conditional access, workload identity scoping, and network segmentation can't be three backlogs owned by three teams. Owned separately, they drift out of sync, and the gap between them becomes the actual attack surface.

The Network Ring

If the Identity Ring answers who, the Network Ring answers how far — and this is where most platforms quietly accumulate the risk they'll spend years paying down.

Start with trust boundaries. Every network has them, whether anyone drew them on purpose or not internet into gateway, gateway into application tier, application into data tier, cloud network into on-premises data center. Each crossing should be a deliberate, enforced checkpoint. In an undesigned network, most of them are just wires.

That distinction matters because of how attackers actually move. Public breach post-mortems tend to describe two phases: an initial foothold through one compromised credential or exposed service, followed by lateral movement toward the system that actually matters.

North-south traffic — between your network and the outside world gets most of the security budget.

East-west traffic — between systems inside your own network gets far less scrutiny, and it's exactly the path lateral movement depends on.

Which makes blast radius a first-class design question, not an incident-response afterthought: if this one identity, this one service, this one subnet is fully compromised, what else becomes reachable? A platform with no east-west segmentation has one blast radius everything. A platform segmented by function and sensitivity, each tier isolated by security group rules that default to deny, turns "everything" into "one tier, at most."

The pattern I return to most often is hub-and-spoke, extended to treat hybrid connectivity as a spoke rather than an exception:

Hub network (shared services)
  ├─ Gateway subnet          — VPN / ExpressRoute / Direct Connect
  ├─ Shared services subnet  — centralized DNS, centralized logging
  └─ Egress control          — forced tunneling / NAT gateway,
                                 all outbound traffic auditable
Spoke — Platform Services
  ├─ Gateway/API tier        — internal-only, no public IP
  └─ Micro-segmented by service, not just by subnet
Spoke — Application Tier
  └─ App services / compute  — reachable only from gateway tier,
                                 east-west denied by default
Spoke — Data Tier
  └─ Private endpoints only  — database, storage, secrets store
     no inbound path except from application tier
     no direct internet route, inbound or outbound
On-premises (via hub)
  └─ Active Directory, legacy systems, existing firewalls —
     reachable only through the gateway subnet, never directly

Hub network (shared services)
  ├─ Gateway subnet          — VPN / ExpressRoute / Direct Connect
  ├─ Shared services subnet  — centralized DNS, centralized logging
  └─ Egress control          — forced tunneling / NAT gateway,
                                 all outbound traffic auditable
Spoke — Platform Services
  ├─ Gateway/API tier        — internal-only, no public IP
  └─ Micro-segmented by service, not just by subnet
Spoke — Application Tier
  └─ App services / compute  — reachable only from gateway tier,
                                 east-west denied by default
Spoke — Data Tier
  └─ Private endpoints only  — database, storage, secrets store
     no inbound path except from application tier
     no direct internet route, inbound or outbound
On-premises (via hub)
  └─ Active Directory, legacy systems, existing firewalls —
     reachable only through the gateway subnet, never directly

Three details here carry more weight than their line count suggests. Micro-segmentation inside a spoke, not just between spokes — two services sharing a subnet don't automatically need to reach each other, and security group rules (or Kubernetes network policies) should enforce that service by service. DNS, which sounds cosmetic until private DNS zones resolving internal names to private endpoints become the difference between a database that's technically reachable from the internet and one that isn't reachable at all, regardless of firewall rules.

And egress control, the piece most often skipped because ingress feels like the dangerous direction a compromised workload with unrestricted outbound access can exfiltrate data without tripping a single inbound rule, while a controlled, logged NAT gateway turns "we don't know what left the network" into "here's exactly what left, when, and from where."

The specific CIDR ranges change from project to project. The shape doesn't: gateway in, gateway tier next, application tier after that, data tier last, hybrid connectivity as just another spoke — every hop enforced by policy, not convention.

For the platform team, this means: networking shouldn't be a one-time diagram a specialist draws before handing the environment over. It should be provisioned through the same templates as everything else versioned and repeatable, not redrawn from scratch each time someone asks for a new environment.

The Platform You Inherit

Most writing about cloud platforms assumes a clean slate cloud-native from the first resource. Most enterprise platforms I've worked on didn't start that way, and advice built on the clean-slate assumption tends not to survive contact with what's already running.

The typical starting point: an Active Directory forest that predates the cloud initiative by a decade. A VMware or Proxmox estate carrying workloads nobody wants to touch mid-migration. Physical firewalls with rule sets accumulated by people who've since left. Site-to-site VPN or MPLS circuits between offices and data centers. A mix of Linux and Windows hosts, patched on inconsistent schedules, some running services with no clear owner left to ask.

Cloud adoption doesn't replace any of that on day one. It sits alongside it, and the Trust Stack's job is to make the seam between old and new as invisible as possible not to pretend the seam isn't there.

That has concrete implications for each ring. Identity federation has to bridge Active Directory to cloud IAM — Entra Connect, AWS IAM Identity Center federation, or an equivalent rather than standing up a second identity system users think about separately.

Networking has to extend hub-and-spoke across a site-to-site VPN or dedicated circuit, treating on-premises as a spoke with its own trust boundary.

Secrets management has to account for credentials already embedded in legacy systems service accounts, application passwords baked into config files that need a deliberate rotation plan rather than a mandate to move everything to the vault by Friday.

Hybrid virtualization platforms like Proxmox earn a place in this conversation that cloud-only writing tends to skip. A read-only audit against a Proxmox cluster — storage configuration, network bridges and VLANs, firewall rules, cluster health, backup coverage surfaces the same category of Trust Stack gaps you'd find in a cloud IAM review: defaults left unchanged since install, backup policies that exist on paper but aren't enforced, segmentation that was correct at deployment and has drifted quietly since. The tooling looks different. The discipline — continuous, low-friction visibility into whether Foundation assumptions still hold is identical.

A Deployment, Walked Through the Trust Stack

The three rings are easier to describe separately than to see working together, so here's one request, followed end-to-end.

A pipeline deploys a new microservice that needs to read from a database.

Identity Ring. The pipeline doesn't hold a database password, or even a cloud credential. It authenticates via OIDC federation — a signed token issued by the CI/CD platform, verified against a trust relationship configured once, in advance. Nothing exists here to leak.

Network Ring. Deployment automation provisions the service into the application-tier spoke, not the data tier. Its security group rules come from the same template every application-tier service uses: inbound only from the gateway tier, outbound only to the database's private endpoint. No route to the internet, either direction, unless a specific rule says otherwise.

Zero Trust evaluation. Every call is checked against workload identity this service, specifically, not "something in the application subnet" and network path this route through this spoke, not merely "somewhere inside the private network." A request matching the identity but arriving from an unexpected path fails closed.

Secrets Ring. At start-up, the service requests its database credential using its own workload identity. The secrets manager checks that this identity is scoped to this secret, issues a short-lived credential, and logs the access. No developer has seen the password. No config file contains it. It rotates automatically before it's old enough to matter.

What made this work wasn't any single control. It was that identity, network path, and secret access all had to agree before the deployment succeeded — each ring's decision legible on its own, auditable independently, enforced by policy rather than someone remembering to configure it correctly. That's the Trust Stack functioning as a stack, not three tools pointed at the same environment.

The Secrets Ring

Buying a secrets manager is not the same as having a secrets strategy — the widest gap of the three rings, because secrets tooling is easy to adopt and secrets discipline is easy to skip.

Azure Key Vault, AWS Secrets Manager, HashiCorp Vault — the tool matters far less than the lifecycle around it. A secret has a birth, a working life, and a death, and a mature platform treats all three as deliberate decisions.

Creation. Secrets should be generated by the platform, never typed by a person. A password created by deployment automation and written directly into the vault never exists anywhere someone can screenshot it or leave it sitting in shell history — which removes an entire class of incident that starts with "someone shared a secret over chat to unblock a deploy."

Rotation, or better, no rotation needed. A secret with no expiry is a secret that will eventually be forgotten, and a forgotten secret is one nobody is watching. Timer-based rotation — even a generous ninety days — forces the platform to prove its automation still works. But the stronger version of this isn't rotation at all: database credentials issued per-connection with a lifespan measured in minutes, or workload-to-workload authentication handled by short-lived certificates through something like SPIFFE/SPIRE instead of a shared static secret, remove the rotation problem by removing the thing being rotated. Static, long-lived secrets should be the fallback for systems that can't yet support anything else not the default design.

Detection. Even a well-designed vault doesn't stop a secret from ending up somewhere it shouldn't — a developer testing locally, a value copied into a script for convenience. Secret-scanning in CI, hosted or open-source, catches this before a commit lands rather than after an audit finds it months later. This is the one control here I'd call non-negotiable regardless of platform maturity: cheap to run, and it catches the mistake at the moment it's most fixable.

Break-glass. Every access policy needs a documented, audited exception path for genuine emergencies. Done well, this looks like just-in-time privileged access: an on-call engineer requests time-boxed elevated access to a specific secret, the request is approved automatically or by a second person depending on sensitivity, access expires on its own, and the sequence is logged. Without this, a platform doesn't have fewer emergencies it has emergencies handled by someone quietly bypassing the controls, instead of by a process built to be bypassed safely and visibly.

The most common secrets anti-pattern, present in some form on nearly every environment I've reviewed, is the plaintext-looking environment variable a value that's obviously a password or API key, sitting unencrypted, checked into a repository or set directly in pipeline variables. Rarely malicious. Almost always a shortcut taken under deadline pressure, with every intention of "moving it to the vault later." Later doesn't come on its own. It has to be enforced by detection, not good intentions.

For the platform team, this means: secrets should be consumed automatically, never requested manually. The moment a human touches a secret in transit, the lifecycle you designed on paper stops being the lifecycle that's actually enforced.

Trust Requires Visibility

A Trust Stack that isn't observable isn't a Trust Stack it's an assumption.

"We enforce least privilege" is a claim nobody can verify after the fact unless every identity grant, every network flow, and every secret access lands somewhere queryable.

Concretely, that means sign-in logs and role-assignment changes shipped to a central workspace, not left sitting in each cloud's native console. Flow logs enabled on every security group by default, not turned on reactively after an incident already happened. Every secrets-manager access event — who, what secret, from which identity, when retained long enough to support an investigation, not just trigger a real-time alert.

None of this replaces the controls described above. It's what turns "we designed it this way" into "we can prove it still works this way," six months after the diagram was drawn and nobody's looked at it since.

Full observability gets its own treatment later in this series, inside Governance audit as a by-product of good design, not an annual event. But visibility into the Trust Stack specifically has to start here, in Foundation, because a compromise you can't see is functionally identical to one you didn't prevent.

Anti-Patterns, in Practice

Four patterns recur often enough to name directly — not as bullet points, but as the shape they actually take when I've found them.

The flat network. Tracing why a low-sensitivity reporting service could open a connection straight to the primary database once took longer than fixing it did, once the path was found. Nobody had built the network for segmentation every "it works from here" request had quietly become an established route over time. The fix wasn't a new firewall rule. It was admitting the network had never had rules to begin with, just default allow.

The shared identity. A pipeline I reviewed used one service principal across four separate applications, because provisioning a new one had once taken a week and nobody wanted to file that request twice. When one of those four applications had a dependency vulnerability, the incident scope wasn't "that application." It was all four, plus everything that identity could reach which, unscoped, was most of the subscription.

The forgotten secret. A build definition I found during a review had a database password sitting in plaintext, set as a pipeline variable roughly two years earlier by an engineer who'd since left. Nobody remembered it was there, and nobody had rotated it there was no reason to notice a secret that never triggered an alert, because nothing was watching for it.

Zero Trust in name only. One environment had genuinely good pieces — private endpoints on every data service, conditional access enforced on admin logins — deployed by two different teams on two different timelines, each unaware of the other's work. The gap between them wasn't a missing control. It was that nobody had ever asked whether the two together actually closed the loop. They didn't, quite.

None of these are exotic. They're the default outcome of moving fast without a Trust Stack deliberately designed to prevent them. Good Foundation design isn't about anticipating sophisticated attacks. It's about removing the easy, boring, entirely predictable mistakes before they compound.

Looking Ahead

The strongest enterprise platforms aren't remembered because they were innovative. They're remembered because they became invisible.

Developers stopped thinking about authentication because identity simply worked. They stopped thinking about connectivity because networking was predictable. They stopped thinking about credentials because the platform handled them securely by default.

That's what a well-built Trust Stack achieves — uncertainty removed before anyone notices it existed. It's the framework I'll keep returning to as this series moves up through the remaining four layers, because none of them are trustworthy on their own terms if the rings underneath aren't.

In the next chapter, I'll build on that foundation by exploring the Platform Services layer — the shared capabilities that turn secure infrastructure into a platform developers can actually use. IaC isn't the platform. It's the platform's plumbing. What you build with that plumbing is where things get interesting.

—

This is Chapter 003 of The Platform Engineering Journal.