Zero Trust Is Not a Product

Before anything else: Zero Trust is an architecture principle, not a product you buy. The phrase has been so thoroughly captured by vendor marketing that it’s worth defining it plainly before proceeding.

Zero Trust means: Never trust, always verify. No implicit trust based on network location. Every request, regardless of source, must be authenticated and authorized.

The original principle came from Google’s BeyondCorp work in the early 2010s. They concluded that perimeter security — “safe inside, dangerous outside” — was broken once an attacker was inside the network. The answer was to make every service verify every request as if it came from an untrusted network.

Photo by FlyD on Unsplash

The Four Pillars of Zero Trust

1. Identity-Based Access Control

Every workload, user, and device has an identity. Access decisions are based on that identity — not network address.

In Kubernetes, this means:

• Service accounts with minimal permissions
• OIDC federation for human access
• Workload identity for cloud API access (no static credentials)

# AWS: Kubernetes service account → IAM role (IRSA)
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service
  namespace: production
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/my-service-role

---
# The pod uses this SA, gets AWS credentials automatically
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      serviceAccountName: my-service
      containers:
      - name: app
        # No AWS credentials in env vars or volume mounts
        image: my-service:latest

2. Mutual TLS (mTLS) Everywhere

In a Zero Trust network, every service-to-service connection is authenticated with mTLS. Both sides present certificates. There’s no such thing as “trusted internal traffic.”

With Istio:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT  # No plaintext traffic, ever

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payments-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: payments-service
  rules:
  - from:
    - source:
        principals:
        - "cluster.local/ns/production/sa/orders-service"
    to:
    - operation:
        methods: ["POST"]
        paths: ["/api/v1/charge"]

This policy says: only orders-service can call /api/v1/charge on the payments service, and only via POST. Every other call is denied.

With Cilium (eBPF-based, no sidecars):

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: payments-l7-policy
spec:
  endpointSelector:
    matchLabels:
      app: payments-service
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: orders-service
    toPorts:
    - ports:
      - port: "8080"
      rules:
        http:
        - method: "POST"
          path: "/api/v1/charge"

3. Least-Privilege Access

Every principal gets the minimum access required. Nothing more.

For Kubernetes RBAC:

# Don't do this
kind: ClusterRoleBinding
metadata:
  name: my-app
roleRef:
  kind: ClusterRole
  name: cluster-admin  # ❌ Overly permissive

---
# Do this
kind: Role
metadata:
  name: config-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list"]
  resourceNames: ["app-config"]  # Only this specific ConfigMap

---
kind: RoleBinding
metadata:
  name: my-app-config-reader
subjects:
- kind: ServiceAccount
  name: my-service
roleRef:
  kind: Role
  name: config-reader

4. Continuous Verification and Observability

Zero Trust doesn’t just apply at connection establishment. Access must be continuously verified, and all access must be logged.

# Falco rule: detect unexpected process in production container
- rule: Unexpected Process in Production Container
  desc: A process other than the expected app binary executed
  condition: >
    spawned_process and
    container and
    k8s.ns.name = "production" and
    not proc.name in (expected_processes)
  output: >
    Unexpected process started (user=%user.name
    command=%proc.cmdline container=%container.name 
    namespace=%k8s.ns.name)
  priority: WARNING

The Zero Trust Implementation Roadmap

Phase 1: Identity Foundation (Weeks 1-4)

• Rotate all static credentials to workload identity
• Implement OIDC for human access to Kubernetes
• Enable audit logging everywhere

Phase 2: mTLS and Service Identity (Weeks 4-8)

• Deploy Istio or Cilium with mTLS in permissive mode
• Map service dependencies
• Switch to strict mode (break nothing first)

Phase 3: Authorization Policies (Weeks 8-16)

• Implement default-deny policies
• Add explicit allow policies per service
• Integrate with security information and event management (SIEM)

Phase 4: Continuous Monitoring (Ongoing)

• Runtime security with Falco/Tetragon
• Policy drift detection
• Quarterly access reviews

Common Mistakes

Mistake 1: Treating the VPN as Zero Trust A VPN moves the trust boundary, it doesn’t eliminate it. Once you’re on the VPN, you’re “inside” and trusted. That’s not Zero Trust.

Mistake 2: Starting with network segmentation Network segmentation is a legacy approach. Start with identity, then add network controls on top.

Mistake 3: Going from zero to strict too fast Enable mTLS in permissive mode first. Map your traffic. Understand dependencies. Then enforce.

Mistake 4: Forgetting CI/CD pipelines Your deployment pipeline has broad access to your infrastructure. Apply Zero Trust to it too.

The State of Zero Trust Tooling in 2026

The mature options:

Is Zero Trust Worth the Complexity?

For most teams: yes, but phase it. The full Zero Trust posture is genuinely complex, but the individual components are valuable standalone:

• mTLS between services catches a whole class of network-level attacks
• Workload identity eliminates credential sprawl
• Least-privilege RBAC limits blast radius from compromised services

You don’t have to do everything at once. Start with the highest-value pieces, measure the security improvement, and expand from there.

The threat model in 2026 — with supply chain attacks, AI-assisted phishing, and insider threats — makes the “trusted inside perimeter” model increasingly untenable. Zero Trust is the direction. How fast you get there depends on your risk tolerance and engineering capacity.

NIST has a solid Zero Trust Architecture guide: SP 800-207. Worth reading before starting implementation.

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)