--- title: "Zero Trust Architecture: Principles, Identity-Based Access, Microsegmentation, and Implementation" description: "Implementing zero trust from principles to practice — identity verification on every request, microsegmentation, BeyondCorp patterns, policy enforcement points, and practical steps for moving from perimeter security to zero trust." url: https://agent-zone.ai/knowledge/security/zero-trust-architecture/ section: knowledge date: 2026-02-22 categories: ["security"] tags: ["zero-trust","identity","microsegmentation","beyondcorp","authentication","network-security","least-privilege"] skills: ["zero-trust-design","identity-based-access","microsegmentation","policy-enforcement"] tools: ["istio","envoy","opa","spiffe","wireguard","tailscale"] levels: ["intermediate"] word_count: 1596 formats: json: https://agent-zone.ai/knowledge/security/zero-trust-architecture/index.json html: https://agent-zone.ai/knowledge/security/zero-trust-architecture/?format=html api: https://api.agent-zone.ai/api/v1/knowledge/search?q=Zero+Trust+Architecture%3A+Principles%2C+Identity-Based+Access%2C+Microsegmentation%2C+and+Implementation --- # Zero Trust Architecture Zero trust means no implicit trust. A request from inside the corporate network is treated with the same suspicion as a request from the public internet. Every request must prove who it is, what it is allowed to do, and that it is coming from a healthy device or service — regardless of network location. This is not a product you buy. It is an architectural approach that requires changes to authentication, authorization, network design, and monitoring. ## Core Principles ### 1. Verify Explicitly Every request is authenticated and authorized based on all available data: identity, device health, location, resource sensitivity, and behavioral patterns. There is no "trusted zone" where requests skip verification. In practice this means: - Every API call carries credentials (tokens, certificates, or both). - Every service validates those credentials before processing the request. - Network position does not grant access. Being inside the VPN or the same Kubernetes cluster does not bypass authentication. ### 2. Least Privilege Access Grant the minimum permissions needed for the task. Permissions are scoped by: - **Identity** — Which user or service. - **Resource** — Which specific data or endpoint. - **Action** — Read, write, delete, admin. - **Time** — Short-lived tokens, just-in-time access. - **Context** — Device posture, location, risk score. Overly broad permissions are the root cause of most privilege escalation attacks. An application that has read access to every database table will eventually be exploited to read data it should not. ### 3. Assume Breach Design systems assuming an attacker is already inside the network. This changes how you architect: - Encrypt all internal traffic (mTLS between services). - Segment networks so a compromised service cannot reach everything. - Log everything for forensic analysis. - Detect lateral movement by monitoring unusual access patterns. - Limit blast radius by isolating services and data stores. ## From Perimeter Security to Zero Trust ### The Perimeter Model (What We Are Replacing) ``` Internet ──→ Firewall ──→ Internal Network (trusted) ├── Service A ──→ Service B (no auth) ├── Database (accessible from internal) └── Admin panel (accessible from VPN) ``` Once past the firewall, everything trusts everything. An attacker who compromises one service has lateral access to all internal services and databases. ### The Zero Trust Model ``` Internet ──→ Identity-Aware Proxy ──→ Service A │ ├── mTLS + authz ──→ Service B ├── mTLS + authz ──→ Database (scoped access) └── Denied ──→ Admin panel (wrong identity) Internal Network: Service C ──→ mTLS + authz ──→ Service D │ └── Denied ──→ Service E (no policy allows it) ``` Every connection requires identity proof and authorization, whether it originates from the internet or from the next pod in the same namespace. ## Identity: The Foundation Zero trust replaces network location with identity as the access control primitive. Identity must be strong, verifiable, and tied to the specific entity making the request. ### Service Identity with SPIFFE SPIFFE (Secure Production Identity Framework for Everyone) provides a standard for service identity: ``` spiffe://example.com/service/payment-api spiffe://example.com/service/order-processor spiffe://example.com/service/user-service ``` Each service gets a SPIFFE ID and a short-lived X.509 certificate (SVID) that proves it. SPIRE (the SPIFFE Runtime Environment) automates certificate issuance and rotation. ```yaml # SPIRE server entry: payment-api can talk to order-processor apiVersion: spire.spiffe.io/v1alpha1 kind: ClusterSPIFFEID metadata: name: payment-api spec: spiffeIDTemplate: "spiffe://example.com/service/payment-api" podSelector: matchLabels: app: payment-api dnsNameTemplates: - "payment-api.{{ .PodMeta.Namespace }}.svc.cluster.local" ``` ### Service Mesh Identity Istio and Linkerd implement service identity using mTLS certificates issued per-pod: ``` Istio identity: spiffe://cluster.local/ns/my-app/sa/payment-api ``` The service mesh handles certificate issuance, rotation, and mTLS negotiation automatically. Authorization policies reference these identities: ```yaml apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: payment-api-policy namespace: my-app spec: selector: matchLabels: app: payment-api rules: - from: - source: principals: ["cluster.local/ns/my-app/sa/order-processor"] to: - operation: methods: ["POST"] paths: ["/api/v1/payments"] ``` Only `order-processor` can call `payment-api`, and only the POST method on the payments endpoint. Everything else is denied. ### User Identity For human users, zero trust requires strong authentication: - **Single Sign-On (SSO)** with a central identity provider (Okta, Azure AD, Google Workspace). - **Multi-Factor Authentication (MFA)** on all access to sensitive resources. - **Short-lived sessions** with re-authentication for elevated operations. - **Device posture checks** — is the device managed, encrypted, up to date? ## Microsegmentation Traditional networks use VLANs and subnets for segmentation. Microsegmentation creates fine-grained boundaries around individual services or workloads. ### Kubernetes Network Policies Network policies are the simplest form of microsegmentation in Kubernetes: ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: payment-api namespace: my-app spec: podSelector: matchLabels: app: payment-api policyTypes: - Ingress - Egress ingress: - from: - podSelector: matchLabels: app: order-processor ports: - port: 8080 protocol: TCP egress: - to: - podSelector: matchLabels: app: postgres ports: - port: 5432 protocol: TCP - to: # DNS - namespaceSelector: {} ports: - port: 53 protocol: UDP protocol: TCP ``` This policy says: `payment-api` can only receive traffic from `order-processor` on port 8080, and can only send traffic to `postgres` on port 5432 (plus DNS). All other traffic is blocked. ### Default Deny The first step in microsegmentation is denying all traffic by default: ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny namespace: my-app spec: podSelector: {} policyTypes: - Ingress - Egress ``` Then explicitly allow only the traffic that should exist. This is the network equivalent of least privilege. ### Service Mesh Segmentation Network policies operate at L3/L4 (IP and port). Service mesh policies operate at L7 (HTTP method, path, headers): ```yaml # Istio: allow only GET /api/v1/products from frontend apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: product-api-policy spec: selector: matchLabels: app: product-api rules: - from: - source: principals: ["cluster.local/ns/my-app/sa/frontend"] to: - operation: methods: ["GET"] paths: ["/api/v1/products", "/api/v1/products/*"] ``` L7 policies are more precise. A network policy can allow traffic from frontend to product-api on port 8080. A service mesh policy can further restrict it to GET requests on specific paths. Use both layers. Network policies prevent unauthorized network access. Service mesh policies enforce application-level authorization. ## Policy Enforcement ### Open Policy Agent (OPA) OPA is a general-purpose policy engine that evaluates access decisions using Rego policies: ```rego # policy.rego package authz default allow = false # Allow if the caller's service identity matches an allowed caller allow { input.source.principal == "cluster.local/ns/my-app/sa/order-processor" input.destination.service == "payment-api" input.request.method == "POST" } # Allow health checks from anywhere allow { input.request.path == "/healthz" input.request.method == "GET" } ``` OPA integrates with Envoy (as an external authorizer), Kubernetes (as an admission controller via Gatekeeper), and application code (as a library or sidecar). ### Policy as Code Store policies in Git alongside application code: ``` policies/ authz/ payment-api.rego order-processor.rego network/ default-deny.yaml payment-api.yaml admission/ pod-security.rego ``` Review policies in pull requests. Test policies in CI. Deploy policies through the same GitOps pipeline as applications. This makes security changes auditable and reversible. ## BeyondCorp: Zero Trust for User Access Google's BeyondCorp model replaces VPNs with identity-aware proxies: ``` Traditional: User → VPN → Internal network → Application (trusted because VPN) BeyondCorp: User → Identity-Aware Proxy → Application │ ├── Verify user identity (SSO + MFA) ├── Check device posture (managed? encrypted? patched?) ├── Evaluate access policy (role + resource + context) └── Allow or deny per-request ``` ### Identity-Aware Proxy Implementation ``` User IAP / Access Proxy Application │ │ │ │── Request ──────────────→│ │ │ │── Check auth cookie ─────────│ │ │ (redirect to IDP if none) │ │ │ │ │ │── Evaluate policy ───────────│ │ │ (user + device + resource) │ │ │ │ │ │── Forward with identity ────→│ │ │ (X-Forwarded-User, etc.) │ │ │ │ │←── Response ─────────────│←─────────────────────────────│ ``` Products implementing this pattern: Google IAP, Cloudflare Access, Pomerium, Ory Oathkeeper, OAuth2 Proxy. Example with Cloudflare Access: ```yaml # Protect an internal application Application: name: Internal Dashboard domain: dashboard.example.com type: self_hosted Policy: name: engineering-team decision: allow include: - email_domain: example.com require: - group: engineering - device_posture: - disk_encryption: true - os_version_min: "14.0" ``` Users access `dashboard.example.com` directly — no VPN. Cloudflare Access verifies their identity, group membership, and device posture before forwarding the request. ## Implementation Steps Moving to zero trust is incremental. Do not attempt a big-bang migration. ### Phase 1: Visibility Before enforcing policies, understand your current traffic patterns: 1. Deploy a service mesh in permissive mode (Istio with `PERMISSIVE` mTLS). 2. Enable access logging on all services. 3. Map service dependencies: which services talk to which. 4. Identify sensitive data flows: where does PII, financial data, and credentials move. ### Phase 2: Identity Establish strong identity for all entities: 1. Enable mTLS in the service mesh (switch to `STRICT` mode). 2. Implement SSO + MFA for all user-facing access. 3. Replace VPN-only access with an identity-aware proxy for internal tools. 4. Issue service accounts and API keys with specific scopes instead of shared credentials. ### Phase 3: Segmentation Restrict traffic to only what is needed: 1. Apply default-deny network policies in all namespaces. 2. Create explicit allow policies for each service's required communications. 3. Add service mesh authorization policies for L7 control. 4. Restrict database access to specific services (not the entire namespace). ### Phase 4: Continuous Verification Move from point-in-time checks to continuous evaluation: 1. Monitor for anomalous access patterns (unusual source, time, volume). 2. Re-evaluate access decisions on context changes (device posture degrades, location changes). 3. Implement just-in-time access for privileged operations (admin access granted for 1 hour, then revoked). 4. Automate policy testing and deployment through CI/CD. ## Common Mistakes 1. **Treating zero trust as a product purchase.** No single vendor delivers zero trust. It is an architecture that requires changes across identity, network, application, and monitoring layers. 2. **Deploying microsegmentation without understanding traffic flows first.** Default-deny in a namespace you do not understand breaks applications. Observe first, then enforce. 3. **Relying on network policies alone.** Network policies enforce IP and port rules. They do not authenticate callers or authorize actions. Combine with service mesh policies and application-level auth. 4. **Exempting internal services from authentication.** The most common zero trust failure is "but that service is internal." Internal services are exactly where lateral movement happens after an initial compromise. 5. **Not testing policies before enforcement.** Deploy policies in audit/dry-run mode first. Istio's `PERMISSIVE` mode and OPA's decision logging let you see what would be blocked without actually blocking it.