When Google's BeyondCorp team set out to eliminate their corporate network perimeter, they faced a fundamental challenge: if you can't trust the network, what can you trust?

Their answer transformed enterprise security: trust identity, not location.

Instead of asking "Is this request coming from inside our network?", Zero Trust asks "Who is making this request, and are they authorized for this specific action?" This shift from network-centric to identity-centric security is perhaps the most profound change in how we design secure systems.

The identity challenge in distributed systems:

In a monolithic application, identity was relatively simple—users logged in, and the application managed sessions. In a distributed system with hundreds of microservices, the identity landscape explodes in complexity:

• Human identities: Employees, contractors, customers, partners
• Service identities: Each microservice needs a verified identity
• Device identities: Phones, laptops, IoT devices, servers
• Workload identities: Containers, VMs, serverless functions—ephemeral by nature

Zero Trust requires strong, verified identity for all of these before granting any access.

Traditional access control relied heavily on network location as a proxy for identity:

• IP-based ACLs: "Traffic from 10.0.0.0/8 is internal and trusted"
• Firewall zones: "Traffic from the DMZ goes to the frontend, trusted zone to backend"
• VPN access: "If you're on the VPN, you're an employee"

This approach made a dangerous assumption: network location implies identity.

Why this assumption fails:

1. IP addresses are not authenticated

An IP address proves nothing about who is making a request. Any device on a network can claim any IP through:

• IP spoofing
• Compromised devices using legitimate IPs
• ARP spoofing to intercept traffic
• NAT making many users appear as one IP

Reality of IP-based "identity":

Firewall Rule: Allow 10.0.1.50 → database:5432

What we assume:        What might actually be true:
10.0.1.50 = App Server  10.0.1.50 = Attacker who compromised app server
                        10.0.1.50 = Malicious insider on that host
                        10.0.1.50 = Lateral movement from another breach
                        10.0.1.50 = Misconfigured or rogue device

2. Cloud and containers make IPs ephemeral

In dynamic environments, IP addresses change constantly:

• Containers get new IPs on every restart
• Autoscaling creates pods with unpredictable IPs
• Serverless functions have no persistent IP
• Cloud instances can be replaced any time

IP-based rules become impossible to maintain accurately.

3. Remote work eliminates network boundaries

With employees working from home, coffee shops, and co-working spaces:

• They're on networks you don't control
• VPNs just extend the perimeter problem
• Device location varies constantly

The concept of "inside the network" is meaningless.

Zero Trust requires identity verification at multiple levels. Understanding this hierarchy is essential for comprehensive identity-based access control.

Combining identity signals:

The most secure Zero Trust implementations combine multiple identity signals:

Access Request Evaluation:

┌─────────────────────────────────────────────────────────────────────────┐
│                          Access Request                                  │
│  From: alice@company.com                                                 │
│  Device: laptop-12345.corporate.com                                      │
│  Application: finance-dashboard                                          │
│  Resource: /api/reports/quarterly                                        │
└─────────────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                    Identity Verification Cascade                         │
│                                                                          │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐          │
│  │  User Identity  │  │ Device Identity │  │ App Identity    │          │
│  │                 │  │                 │  │                 │          │
│  │  ✓ Valid user   │  │  ✓ Managed      │  │  ✓ Known app    │          │
│  │  ✓ MFA passed   │  │  ✓ Compliant    │  │  ✓ Valid cert   │          │
│  │  ✓ Not revoked  │  │  ✓ Encrypted    │  │  ✓ Not expired  │          │
│  │  ✓ Group: Finance│  │  ✓ Patched     │  │                 │          │
│  └─────────────────┘  └─────────────────┘  └─────────────────┘          │
│                                                                          │
│  Combined Signal: All identities verified + context acceptable           │
│  Decision: ALLOW access to /api/reports/quarterly with audit logging    │
└─────────────────────────────────────────────────────────────────────────┘

The identity chain:

In a typical request flow through a distributed system, identity must be verified at each hop:

1. User authenticates to the frontend application
2. Frontend's service identity authenticates to the API gateway
3. API gateway verifies both user identity (JWT) and frontend identity (mTLS)
4. Backend services verify the calling service's identity
5. Database access uses the service's database identity

Each hop requires verified identity—no implicit trust based on being "internal."

SPIFFE (Secure Production Identity Framework for Everyone) is a set of open-source standards for workload identity, and SPIRE (SPIFFE Runtime Environment) is the reference implementation. Together, they provide a foundation for identity-based access in distributed systems.

Why SPIFFE matters:

Before SPIFFE, workload identity was fragmented:

• Each cloud provider had its own mechanism
• Kubernetes had service accounts with limited portability
• Custom certificate infrastructure was complex to manage
• No standard way to express or verify workload identity

SPIFFE provides a universal, platform-agnostic standard for workload identity.

Core SPIFFE concepts:

1. SPIFFE ID

A SPIFFE ID is a URI that uniquely identifies a workload:

spiffe://trust-domain/path/to/workload

Examples:
spiffe://prod.company.com/payments/payment-service
spiffe://prod.company.com/ns/production/sa/frontend
spiffe://dev.company.com/workloads/testing-service

Components:

• Trust domain: The root of trust (like a certificate authority domain)
• Path: Hierarchical identifier for the workload

2. SVID (SPIFFE Verifiable Identity Document)

An SVID is a cryptographically signed document that contains the SPIFFE ID. Two formats:

• X.509-SVID: X.509 certificate with SPIFFE ID in the URI SAN field
• JWT-SVID: JWT token with SPIFFE ID in the subject claim

X.509-SVID Certificate:
┌─────────────────────────────────────────────────────────────┐
│  Subject: CN=payment-service                                │
│  Subject Alternative Name:                                  │
│    URI: spiffe://prod.company.com/payments/payment-service  │
│  Validity: Not Before: 2024-01-15T10:00:00Z                │
│            Not After:  2024-01-15T11:00:00Z (1 hour!)      │
│  Issuer: CN=SPIRE Server CA,OU=SPIRE,O=Company             │
│  Signature: [cryptographic signature from SPIRE CA]         │
└─────────────────────────────────────────────────────────────┘

Note: Short validity periods (minutes to hours) limit exposure from stolen credentials

SPIRE architecture:

┌─────────────────────────────────────────────────────────────────────────┐
│                           SPIRE Architecture                             │
└─────────────────────────────────────────────────────────────────────────┘

                    ┌────────────────────────────────┐
                    │         SPIRE Server           │
                    │  ┌──────────────────────────┐  │
                    │  │   Registration API       │  │ ← Configure which workloads
                    │  │   (workload → SPIFFE ID)│  │   get which identities
                    │  └──────────────────────────┘  │
                    │  ┌──────────────────────────┐  │
                    │  │   Certificate Authority  │  │ ← Signs SVIDs
                    │  │   (issues SVIDs)         │  │
                    │  └──────────────────────────┘  │
                    │  ┌──────────────────────────┐  │
                    │  │   Node Attestation       │  │ ← Verifies node identity
                    │  │   (validates SPIRE agents│  │   (cloud metadata, TPM, etc.)
                    │  └──────────────────────────┘  │
                    └───────────────┬────────────────┘
                                    │
           ┌────────────────────────┼────────────────────────┐
           │                        │                        │
           ▼                        ▼                        ▼
   ┌───────────────┐        ┌───────────────┐        ┌───────────────┐
   │  SPIRE Agent  │        │  SPIRE Agent  │        │  SPIRE Agent  │
   │   (Node 1)    │        │   (Node 2)    │        │   (Node 3)    │
   └───────┬───────┘        └───────┬───────┘        └───────┬───────┘
           │                        │                        │
           ▼                        ▼                        ▼
   ┌───────────────┐        ┌───────────────┐        ┌───────────────┐
   │   Workload A  │        │   Workload B  │        │   Workload C  │
   │   (gets SVID) │        │   (gets SVID) │        │   (gets SVID) │
   └───────────────┘        └───────────────┘        └───────────────┘

How SPIRE issues identity:

1. Node attestation: SPIRE Server verifies SPIRE Agent's node is legitimate (using AWS instance metadata, Kubernetes tokens, TPM, etc.)

2. Workload attestation: SPIRE Agent verifies workload is legitimate (using Kubernetes pod info, Docker labels, process UID, etc.)

3. SVID issuance: SPIRE Server issues short-lived certificate to verified workload

4. Automatic rotation: SPIRE Agent automatically renews certificates before expiry

Each major cloud provider offers identity mechanisms for workloads. Understanding these is essential for Zero Trust in cloud environments.

AWS Identity and Access Management (IAM)

AWS provides multiple mechanisms for workload identity:

IAM Roles for EC2:

• Instances assume roles via instance metadata service (IMDS)
• Temporary credentials automatically rotated
• Credentials available at http://169.254.169.254/latest/meta-data/iam/security-credentials/

IAM Roles for Service Accounts (IRSA) in EKS:

# Kubernetes ServiceAccount linked to AWS IAM role
apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-service
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/PaymentServiceRole

# Pod automatically gets AWS credentials for this role
apiVersion: v1
kind: Pod
metadata:
  name: payment-pod
spec:
  serviceAccountName: payment-service  # Uses IRSA

Lambda execution roles:

• Each Lambda function has an execution role
• Credentials injected automatically into function environment

Google Cloud Identity

Workload Identity for GKE:

# Kubernetes ServiceAccount linked to GCP service account
apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-service
  annotations:
    iam.gke.io/gcp-service-account: payment@project.iam.gserviceaccount.com

Service Account Keys vs Workload Identity:

• Avoid long-lived service account keys (security risk)
• Prefer Workload Identity Federation for GKE workloads
• Use identity federation for external workloads

Azure Identity

Managed Identities:

• System-assigned: Tied to Azure resource lifecycle
• User-assigned: Independent identity, can be shared

Azure AD Workload Identity for AKS:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-service
  annotations:
    azure.workload.identity/client-id: <client-id>
    azure.workload.identity/tenant-id: <tenant-id>

Kubernetes provides multiple identity layers that work together with service meshes and external identity systems.

Kubernetes identity components:

1. Service Accounts

Every pod runs with a service account identity:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-service
  namespace: production
---
apiVersion: v1
kind: Pod
metadata:
  name: payment-pod
spec:
  serviceAccountName: payment-service
  # Pod gets token at /var/run/secrets/kubernetes.io/serviceaccount/token

The service account token:

• Is a JWT signed by the Kubernetes API server
• Contains: namespace, service account name, pod name
• Can be used for Kubernetes API authentication
• Can be used for workload identity federation (IRSA, Workload Identity)

2. Projected Service Account Tokens

Modern Kubernetes uses bound, time-limited tokens:

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: app-token
  volumes:
  - name: app-token
    projected:
      sources:
      - serviceAccountToken:
          path: token
          expirationSeconds: 3600  # 1 hour expiry
          audience: "api.company.com"  # Specific audience

3. Service Mesh Identity (Istio Example)

Istio builds on Kubernetes identity to provide mTLS:

Kubernetes ServiceAccount: payment-service in production namespace

          ↓ Istio Citadel/istiod issues certificate

SPIFFE ID: spiffe://cluster.local/ns/production/sa/payment-service

          ↓ Certificate mounted in Envoy sidecar

mTLS: Payment pod proves identity to other pods cryptographically

AuthorizationPolicy using identity:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payment-access
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  rules:
  - from:
    - source:
        # Only specific service identities can call payment-service
        principals:
        - "cluster.local/ns/production/sa/checkout-service"
        - "cluster.local/ns/production/sa/order-service"
    to:
    - operation:
        methods: ["POST"]
        paths: ["/api/payments/*"]

This policy:

• Identifies callers by their service account (not IP)
• Applies regardless of pod IP (survives restarts, scaling)
• Is enforced cryptographically via mTLS
• Denies other principals implicitly

Identity-Aware Proxies (IAPs) are a key architectural component in Zero Trust. They sit in front of applications and enforce identity verification before allowing access.

How identity-aware proxies work:

┌─────────────────────────────────────────────────────────────────────────┐
│                     Identity-Aware Proxy Flow                            │
└─────────────────────────────────────────────────────────────────────────┘

    User Request                                              Application
         │                                                         │
         ▼                                                         │
   ┌───────────────────────────────────────────────────────┐      │
   │              Identity-Aware Proxy (IAP)                │      │
   │                                                        │      │
   │  1. User already authenticated?                        │      │
   │     NO  → Redirect to IdP (Okta, Azure AD, etc.)      │      │
   │     YES → Continue                                     │      │
   │                                                        │      │
   │  2. Verify identity token (JWT validation)             │      │
   │                                                        │      │
   │  3. Check device posture (optionally)                  │      │
   │     - Is device managed?                               │      │
   │     - Is device compliant?                             │      │
   │                                                        │      │
   │  4. Evaluate access policy                             │      │
   │     - Is user authorized for this application?         │      │
   │     - Any conditional access requirements?             │      │
   │                                                        │      │
   │  5. Pass request to application with identity headers  │      │
   └──────────────────────────┬────────────────────────────┘      │
                              │                                    │
                              │ X-User-Email: alice@company.com    │
                              │ X-User-Groups: ["engineering"]     │
                              │ X-Device-Id: laptop-12345          │
                              ▼                                    │
                         Application                               │
                    (trusts proxy headers)◀────────────────────────┘

Beyond web applications:

Identity-aware proxies aren't limited to HTTP. Modern solutions support:

• SSH access: Authenticate to servers through identity proxy (no SSH keys to manage)
• Database access: Proxy database connections with identity verification
• Kubernetes access: Access clusters through identity verification, not kubeconfig files
• RDP/VNC: Remote desktop through identity proxy

Example: Teleport for infrastructure access:

Traditional SSH access:
1. Generate SSH key pair
2. Add public key to server authorized_keys
3. SSH with private key
4. Keys live forever, hard to revoke, no MFA

Teleport (identity-first SSH):
1. Authenticate to Teleport with MFA
2. Teleport issues short-lived SSH certificate (hours, not forever)
3. SSH with certificate
4. Every session logged, easily revoked, MFA enforced

Moving from network-based to identity-based access is a journey. Here's a practical implementation approach:

Common implementation patterns:

Pattern 1: Service mesh for east-west traffic

Internal services ←→ mTLS via Istio/Linkerd ←→ Identity-based authorization
- Every service has SPIFFE identity
- Every call is encrypted and authenticated
- AuthorizationPolicy enforces access rules

Pattern 2: Identity-aware proxy for north-south traffic

Users → Identity-Aware Proxy → Internal applications
- Users authenticate via SSO with MFA
- Proxy verifies identity and device posture
- Per-application authorization policies

Pattern 3: Workload identity for cloud resources

Kubernetes pods → IRSA/Workload Identity → Cloud resources (S3, RDS, etc.)
- No static credentials in pods
- Automatic credential rotation
- Fine-grained IAM policies per workload

Let's consolidate the key concepts of identity-based access in Zero Trust:

What's next:

With identity as the foundation of trust, we now need to understand how to implement Zero Trust in practice. The final page of this module brings together everything we've learned: the philosophy of never trust/always verify, the NIST principles, micro-segmentation, and identity-based access. We'll explore Zero Trust implementation patterns and create a roadmap for deploying Zero Trust in your organization.