<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1563986768609-322da13575f3?w=1200&amp;auto=format&amp;fit=crop&amp;q=80"><h2 id="zero-trust-is-not-a-product">Zero Trust Is Not a Product</h2>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 <a href="https://cloud.google.com/beyondcorp">BeyondCorp</a> 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.<img src="https://images.unsplash.com/photo-1614064641938-3bbee52942c7?w=1000&amp;auto=format&amp;fit=crop&amp;q=80" alt="Network Security Concept"> Photo by FlyD on Unsplash<h2 id="the-four-pillars-of-zero-trust">The Four Pillars of Zero Trust</h2><h3 id="1-identity-based-access-control">1. Identity-Based Access Control</h3>Every workload, user, and device has an identity. Access decisions are based on that identity — not network address.In Kubernetes, this means:<ul><li>Service accounts with minimal permissions</li><li>OIDC federation for human access</li><li>Workload identity for cloud API access (no static credentials)</li></ul><div><pre><code># 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
</code></pre></div><h3 id="2-mutual-tls-mtls-everywhere">2. Mutual TLS (mTLS) Everywhere</h3>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:<div><pre><code>apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
 name: default
 namespace: production
spec:
 mtls:
 mode: STRICT # No plaintext traffic, ever
</code></pre></div><div><pre><code>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"]
</code></pre></div>This policy says: only <code>orders-service</code> can call <code>/api/v1/charge</code> on the payments service, and only via POST. Every other call is denied.With Cilium (eBPF-based, no sidecars):<div><pre><code>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"
</code></pre></div><h3 id="3-least-privilege-access">3. Least-Privilege Access</h3>Every principal gets the minimum access required. Nothing more.For Kubernetes RBAC:<div><pre><code># 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
</code></pre></div><h3 id="4-continuous-verification-and-observability">4. Continuous Verification and Observability</h3>Zero Trust doesn’t just apply at connection establishment. Access must be continuously verified, and all access must be logged.<div><pre><code># 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: &gt;
 spawned_process and
 container and
 k8s.ns.name = "production" and
 not proc.name in (expected_processes)
 output: &gt;
 Unexpected process started (user=%user.name
 command=%proc.cmdline container=%container.name 
 namespace=%k8s.ns.name)
 priority: WARNING
</code></pre></div><h2 id="the-zero-trust-implementation-roadmap">The Zero Trust Implementation Roadmap</h2><h3 id="phase-1-identity-foundation-weeks-1-4">Phase 1: Identity Foundation (Weeks 1-4)</h3><ul><li>Rotate all static credentials to workload identity</li><li>Implement OIDC for human access to Kubernetes</li><li>Enable audit logging everywhere</li></ul><h3 id="phase-2-mtls-and-service-identity-weeks-4-8">Phase 2: mTLS and Service Identity (Weeks 4-8)</h3><ul><li>Deploy Istio or Cilium with mTLS in permissive mode</li><li>Map service dependencies</li><li>Switch to strict mode (break nothing first)</li></ul><ul><li>Implement default-deny policies</li><li>Add explicit allow policies per service</li><li>Integrate with security information and event management (SIEM)</li></ul><h3 id="phase-4-continuous-monitoring-ongoing">Phase 4: Continuous Monitoring (Ongoing)</h3><ul><li>Runtime security with Falco/Tetragon</li><li>Policy drift detection</li><li>Quarterly access reviews</li></ul><h2 id="common-mistakes">Common Mistakes</h2>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 mature options:<table><thead><tr><th>Layer</th><th>Tool</th><th>Notes</th></tr></thead><tbody><tr><td>Service mesh mTLS</td><td>Istio, Linkerd, Cilium</td><td>Cilium’s eBPF approach has no sidecar overhead</td></tr><tr><td>Identity provider</td><td>Keycloak, Okta, Entra ID</td><td>OIDC/OAuth2</td></tr><tr><td>Secrets management</td><td>HashiCorp Vault, AWS Secrets Manager</td><td>Dynamic credentials, not static</td></tr><tr><td>Runtime security</td><td>Falco, Tetragon</td><td>eBPF-based kernel monitoring</td></tr><tr><td>Policy engine</td><td>OPA/Gatekeeper, Kyverno</td><td>Admission control</td></tr><tr><td>Access proxy</td><td>Teleport, Pomerium, Zitadel</td><td>Replace bastion hosts</td></tr></tbody></table><h2 id="is-zero-trust-worth-the-complexity">Is Zero Trust Worth the Complexity?</h2>For most teams: yes, but phase it. The full Zero Trust posture is genuinely complex, but the individual components are valuable standalone:<ul><li>mTLS between services catches a whole class of network-level attacks</li><li>Workload identity eliminates credential sprawl</li><li>Least-privilege RBAC limits blast radius from compromised services</li></ul>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.<hr>NIST has a solid Zero Trust Architecture guide: <a href="https://csrc.nist.gov/publications/detail/sp/800/207/final">SP 800-207</a>. Worth reading before starting implementation. <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

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:
Layer
      Tool
      Notes
    
Service mesh mTLS
      Istio, Linkerd, Cilium
      Cilium’s eBPF approach has no sidecar overhead
    
Identity provider
      Keycloak, Okta, Entra ID
      OIDC/OAuth2
    
Secrets management
      HashiCorp Vault, AWS Secrets Manager
      Dynamic credentials, not static
    
Runtime security
      Falco, Tetragon
      eBPF-based kernel monitoring
    
Policy engine
      OPA/Gatekeeper, Kyverno
      Admission control
    
Access proxy
      Teleport, Pomerium, Zitadel
      Replace bastion hosts
    
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.

Zero Trust Architecture in Practice: Beyond the Buzzword

댓글