The phrase "Zero Trust" has been marketing copy for long enough that most engineers roll their eyes when they hear it. That's fair — vendors have slapped it on everything from VPNs to single sign-on dashboards, which has thoroughly diluted what it actually means.
But underneath the buzzword is a genuinely useful architectural principle: never assume that something is safe just because it's inside your network perimeter. In a world where breaches are often lateral — an attacker gets in through a phishing email and then moves horizontally through your infrastructure — this assumption is genuinely dangerous.
This post is for engineering teams who want to move from "we have a firewall" to something that would actually slow down an attacker who's already inside.
What Zero Trust Actually Means in Practice
The original Zero Trust model, developed by John Kindervag at Forrester in 2010, boils down to three things:
- Verify explicitly — Always authenticate and authorize, using all available data points
- Use least-privilege access — Limit access to only what's needed for the current task
- Assume breach — Design as if the attacker is already inside; focus on limiting blast radius
What this means practically is a shift from "is this request coming from inside the VPN?" to "is this specific identity authorized to perform this specific action on this specific resource at this specific time?"
That's a fundamentally different question — and it has real implications for how you build your CI/CD pipelines, cloud IAM policies, and service-to-service authentication.
The Three Places Zero Trust Matters Most for DevOps
1. Your CI/CD Pipeline
Most CI/CD pipelines are a security disaster waiting to happen, and most teams don't know it. Here's a common pattern:
- A long-lived
AWS_ACCESS_KEY_IDandAWS_SECRET_ACCESS_KEYstored as CI environment variables - Those credentials have
AdministratorAccessor something close to it - Every pull request — including from forks — can potentially access those credentials
- Those same credentials have been in place for three years and nobody knows who set them up
The Zero Trust alternative:
Use short-lived credentials instead of long-lived secrets. On AWS, this means using OIDC federation — GitHub Actions, GitLab CI, and most modern CI systems can federate with AWS IAM using OIDC tokens. The CI job gets a short-lived, scoped token for that specific run. There's no persistent secret to leak.
# GitHub Actions with OIDC — no stored AWS credentials
jobs:
deploy:
permissions:
id-token: write
contents: read
steps:
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789:role/GitHubActionsDeployer
aws-region: us-east-1
The IAM role GitHubActionsDeployer has a trust policy that only allows tokens from your specific repository and branch. If someone opens a PR from a fork, they can't assume that role. If a credential leaks, it expires in an hour anyway.
GCP has an equivalent via Workload Identity Federation. The pattern is the same — federated short-lived tokens instead of service account keys.
Scope each pipeline stage separately. Your build stage doesn't need deploy permissions. Your test stage doesn't need production database access. Create separate roles or service accounts for each stage and assign only what that stage actually needs.
2. Cloud IAM Policies
The biggest drift from Zero Trust in most cloud environments is IAM policy sprawl. Teams start with broad permissions because it's faster, and then never revisit them.
A practical audit approach:
Start with AWS IAM Access Analyzer or GCP's Policy Analyzer. These tools look at actual API call patterns over the last 90 days and tell you which permissions were actually used. You'll almost always find that a role with 200 allowed actions only exercised 12 of them.
From there, generate least-privilege policies from actual usage:
# AWS — generate a policy from CloudTrail activity
aws iam generate-service-last-accessed-details \
--arn arn:aws:iam::123456789:role/AppServerRole
aws iam get-service-last-accessed-details \
--job-id <job-id>
Use permission boundaries on all automated roles. A permission boundary is a policy that sets the maximum permissions a role can have, even if the role's own policy grants more. This is a belt-and-suspenders approach that limits the blast radius of a misconfigured policy or a compromised credential.
Require MFA for all human users, with no exceptions. This sounds obvious but it's frequently violated for "service" IAM users that humans also log into directly. Audit your IAM users and ensure every human-accessible account requires MFA.
3. Service-to-Service Authentication
Inside a microservices or distributed system, services call each other constantly. The naive implementation trusts anything on the internal network. The Zero Trust implementation requires every service to authenticate before receiving a response.
The two main approaches:
mTLS (mutual TLS) — both the client and server present certificates. This is what service meshes like Istio and Linkerd implement under the hood. It's strong but operationally complex — certificate rotation, CA management, and debugging TLS handshake failures across dozens of services adds real overhead.
SPIFFE/SPIRE — a CNCF standard for service identity. Each workload gets a cryptographically verifiable identity (a SPIFFE Verifiable Identity Document, or SVID) that is short-lived, automatically rotated, and tied to the workload's actual runtime identity (what pod it's running in, what node, etc.). More operationally mature than rolling your own mTLS.
For smaller teams that aren't running a service mesh, a simpler starting point:
- Issue short-lived JWTs from a central auth service
- Each service validates the JWT on every request, checking the issuer, audience, and expiry
- Tokens expire in 15 minutes and are automatically refreshed
This is not as strong as mTLS but it's infinitely better than "same VPC, therefore trusted."
Implementing Zero Trust Incrementally
The mistake teams make is treating Zero Trust as a migration project — something to do all at once on a long-enough runway. It isn't. It's a direction you move in incrementally, starting with your highest-risk systems.
Week 1–2: Audit and inventory
Before changing anything, understand your current state:
- List every long-lived credential in your CI systems
- Run IAM Access Analyzer on your cloud accounts
- Identify every service-to-service call that uses implicit network trust
The output of this audit is your risk prioritization: which things, if compromised, would do the most damage? Start there.
Month 1: Replace long-lived CI credentials
This is the highest-impact, lowest-disruption change you can make. OIDC federation requires almost no application code change — just CI configuration and an IAM trust policy. Most teams can rotate from static credentials to OIDC in a day.
Month 2–3: Scope IAM policies
Use the access analyzer output to generate tighter policies for your three or four most privileged roles. Don't try to fix everything — fix the blast-radius outliers first.
Month 3–6: Service authentication
Introduce lightweight JWT-based auth for your highest-value internal API calls. If you're running Kubernetes, evaluate a service mesh — Linkerd in particular has gotten operationally much more approachable in recent versions.
Common Pitfalls
Confusing Zero Trust with Zero Usability
Zero Trust done poorly creates so much friction that engineers route around it. If your developers are constantly fighting for access to do normal work, you've implemented control theater, not security. The goal is to make the secure path the easy path.
Treating it as a one-time project
IAM drift is constant. New services get deployed with broad permissions because that's what worked before. Automate ongoing policy review — AWS Config rules, GCP Security Command Center findings, and tools like Steampipe can surface policy drift continuously.
Neglecting the secrets themselves
Zero Trust doesn't mean "no secrets." It means "fewer, shorter-lived, more tightly scoped secrets with clear ownership." A secrets management system like HashiCorp Vault, AWS Secrets Manager, or GCP Secret Manager is still necessary — the difference is that secrets should have leases, rotation policies, and audit logs.
Starting with the wrong layer
Teams often start with network segmentation because it's familiar. But in a cloud-native environment, network controls are often less effective than identity controls — an attacker who compromises an EC2 instance is still "inside" any VPC-level controls. Start with identity.
The Scorecard: Where Is Your Team?
Before wrapping up, here's a quick self-assessment. Check each item your team has in place:
- [ ] No long-lived credentials in CI environment variables
- [ ] All CI jobs use OIDC or equivalent short-lived token federation
- [ ] IAM policies reviewed for least-privilege in the last 90 days
- [ ] MFA required for all human cloud access
- [ ] Service-to-service calls authenticated (not just network-trusted)
- [ ] Secrets have rotation policies and audit logs
- [ ] IAM policy drift detected and alerted on automatically
If you checked fewer than three, the highest-leverage thing you can do this week is replace your CI credentials with OIDC federation. It takes a day and immediately removes your biggest blast-radius risk.
Wrapping Up
Zero Trust is not a destination — it's a direction. Most mature engineering organizations are at "moderate trust" at best, and incremental improvements toward explicit verification and least-privilege access make a measurable difference in breach impact even when you're not fully there.
The organizations that get this right don't treat security as a separate initiative. They bake these patterns into how they build — OIDC in the pipeline template, permission boundaries on every automated role, service identity in the service scaffolding. When security is the default path, it doesn't require heroics.
If you're trying to figure out where to start, or you've inherited a cloud environment where nobody's quite sure what has access to what — we can help you work through it.
Working on something similar?
We help engineering teams implement the practices covered in this post. First call is free.
Start a conversation →