提示:本网站现在为维护调试状态

Zero Trust Security Architecture: Never Trust, Always Verify

Choyeon
Choyeon
Sep 29, 2026 1 min read 637 Views
516 words 2,951 chars Updated Nov 8, 2026
Zero Trust Security Architecture: Never Trust, Always Verify
Table of contents

Traditional perimeter security assumed "internal network = safe, VPN = trusted". Cloud-native work, remote teams, and SolarWinds-class supply chain attacks killed that boundary. NIST SP 800-207 defines Zero Trust: every access gets explicit authentication, least-privilege authorization, encryption of all traffic, and end-to-end auditability.

Six Core Pillars Implementation

Identity is the new perimeter: OIDC/SAML SSO with mandatory MFA (TOTP + Passkey minimum), step-up challenges by risk score. Device health: MDM verifies OS patches, EDR, full-disk-encryption; unmanaged devices get only sandboxed access. Microsegmentation: strict service-to-service mTLS, authorization by identity+method+path triples, never by CIDR block.

# ====== 1. SPIFFE SPIRE 颁发服务身份(Workload Identity)======
# 注册 workload registration entry
spire-server entry create   -parentID "spiffe://example.com/k8s-ns/production"   -spiffeID "spiffe://example.com/svc/payment-gateway"   -selector "k8s:ns"   -selector "k8s:sa"   -value "payment-sa"   -dns "payment.internal.example.com"   -ttl 3600

# ====== 2. Istio 授权策略(服务粒度 mTLS + RBAC)======
cat <<'EOF' | kubectl apply -f -
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payment-rbac
  namespace: production
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: payment-gateway
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/production/sa/order-service"
              - "cluster.local/ns/production/sa/checkout-worker"
      to:
        - operation:
            methods: ["POST"]
            paths: ["/v1/charges", "/v1/refunds"]
      when:
        - key: request.auth.claims[roles]
          values: ["payments:write"]
EOF

# ====== 3. OPA Gatekeeper 命名空间隔离 ======
cat <<'EOF' | kubectl apply -f -
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: namespace-must-have-owner-and-tier
spec:
  match:
    kinds: [{ apiGroups: [""], kinds: ["Namespace"] }]
  parameters:
    labels:
      - key: "security.example.com/owner"
      - key: "security.example.com/data-tier"
        allowedRegex: "^(public|internal|restricted)$"
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sDisallowedPrivileged
metadata:
  name: block-privileged-containers-in-restricted
spec:
  match:
    scope: Namespaced
    kinds: [{ apiGroups: [""], kinds: ["Pod"] }]
    labelSelector:
      matchExpressions:
        - key: security.example.com/data-tier
          operator: In
          values: ["restricted"]
EOF

# ====== 4. 身份层:Keycloak MFA + 条件访问策略 ======
# 启用 TOTP OTP + WebAuthn (Passkey) 双重挑战
kcadm.sh update authentication/flows -r master   --alias "browser" -b '{
  "authenticationExecutions": [
    {"authenticator":"auth-cookie","requirement":"ALTERNATIVE"},
    {"authenticator":"identity-provider-redirector","requirement":"ALTERNATIVE"},
    {"level":"1","required":"true","requirement":"CONDITIONAL"},
    {"authenticator":"basic-auth","requirement":"REQUIRED"},
    {"authenticator":"conditional-user-configured","requirement":"REQUIRED"},
    {"authenticator":"otp-form","requirement":"REQUIRED"},
    {"authenticator":"webauthn-authenticator","requirement":"ALTERNATIVE"}
  ]}'

# 按风险评分拒访:异常IP + 非受管设备
kcadm.sh create clients -r master -s clientId=risk-engine   -s 'attributes."risk.score.threshold"=70'   -s 'attributes."risk.check.geo_anomaly"=true'   -s 'attributes."risk.check.managed_device"=true'

# ====== 5. 审计事件转发 SIEM ======
# Falco 运行时异常规则
cat <<'EOF' > /etc/falco/rules.d/zero-trust-rules.yaml
- rule: DB 服务向外建立可疑连接
  desc: MySQL/PG 不应主动发起外连,可能发生数据外泄
  condition: >
    spawned_process and proc.name in (mysql, postgres) and
    outbound and not fd.sip in (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
  output: >
    DB 服务疑似数据外泄 user=%user.name proc=%proc.name
    dst_ip=%fd.sip dst_port=%fd.sport cmd=%proc.cmdline
  priority: CRITICAL
  tags: [zero-trust, data-exfiltration, mitre:T1041]
EOF
systemctl restart falco
falco -r /etc/falco/falco_rules.yaml -r /etc/falco/rules.d/zero-trust-rules.yaml

# ====== 6. Tailscale + OIDC 取代 VPN:每用户按设备入网 ======
tailscale up   --ssh   --accept-dns   --accept-routes   --exit-node=""   --auth-key="tskey-client-XXX"   --advertise-tags=tag:backend,tag:production

# 在 Tailscale ACL 控制台写入最小权限
# "acls": [ { "action": "accept", "src": ["group:sre"],
#             "dst": ["tag:production:*", "tag:backend:22"] } ]

Control Plane + Data Plane + Audit Plane Layers

Control plane (SPIRE/Istio) issues short-lived X.509/SVID (1h TTL so leaks revoke fast); OPA/Gatekeeper does static constraint policy. Data plane per-service Sidecar or kernel eBPF (Cilium) packet-level enforces authorization. Audit plane: Falco runtime rules, K8s audit logs, Keycloak events all streamed to SIEM (Splunk/Elastic) — correlated by user ID + device fingerprint + service request ID for forensic timelines and compliance.

Legacy Perimeter Model Zero Trust Model
Trust premise: internal subnet = auto trusted Trust premise: every request explicitly verified
Auth checkpoint: once on VPN = blanket pass Auth checkpoint: identity + device + risk score, re-evaluated per-request or hourly
Networking: VLAN/ACL segmentation Networking: default-deny, per-service mTLS microsegmentation
Permissions: Coarse roles, constant overprovisioning Permissions: ABAC dynamic attrs + JIT elevation returned after use
Logging: Per-app silos Logging: Structured aggregation full-chain traceable UID
Incident response: Post-breach remediation in days Response: Real-time identity revocation in seconds

Best Practices

Three-phase roadmap: P1 (1-3mo) unify identity + mandate MFA + replace VPN with ZTNA; P2 (3-6mo) K8s mTLS STRICT + authz policies; P3 (6-12mo) runtime eBPF detection + end-to-end audit + ABAC dynamic trust. Zero Trust is not a product — it's architectural evolution requiring sustained investment.

X微博Telegram

About the author

Poll

你最希望 Rosetta 优先加入哪项功能?

社区投票(演示数据,可后台删除)

Comments (6)

0 / 3000
算法小菜鸟
算法小菜鸟Sep 26, 2026

有个小问题:你文中用的是 @Async 注解,这个默认用的是 SimpleAsyncTaskExecutor,生产环境是不是最好手动配一个线程池?

画画的小鱼
画画的小鱼fishgallery.artSep 25, 2026

建议加一下关于幂等性的讨论,现在的分布式系统里这个真的太重要了,很多坑都是没处理好幂等导致的。

代码幽灵
代码幽灵ghostdev.blogSep 24, 2026

写得太好了,终于搞懂了分布式事务的几种方案区别,收藏了!

DevOps小能手
DevOps小能手devops-lab.cnSep 24, 2026

哈哈,楼主的踩坑经历和我一模一样!我当时就是没注意到这个配置,排查了整整两天,看到这篇文章泪目了。

熬夜攻城狮
熬夜攻城狮nightowl.techSep 24, 2026

补充一点:实际使用中如果遇到 MySQL 的 8 小时超时问题,可以在连接串里加 autoReconnect=true 参数,虽然官方不推荐但挺好用的。

独立开发者阿明
独立开发者阿明aming.devSep 24, 2026

太及时了,正好项目里要上 Redis 集群,照着来一遍省了好多事,谢谢!

Related posts

K8s Pod Lifecycle, Init Containers & Sidecars

K8s Pod Lifecycle, Init Containers & Sidecars

Full K8s Pod state machine Pending→Terminated, PostStart/PreStop hooks, Init Container dependency guarantees, Sidecar patterns (istio-proxy, log collectors), and zero-downtime graceful termination configs.

1 min read
Linux Performance Tuning: perf, bpftrace & BCC

Linux Performance Tuning: perf, bpftrace & BCC

Tune Linux across CPU/mem/IO/net: perf for CPU sampling, bpftrace one-liners for kernel tracepoints, BCC classics biolatency/offcputime to pinpoint production bottlenecks with real incident methodology.

1 min read
Rust Ownership & Borrowing: Lifetimes Explained

Rust Ownership & Borrowing: Lifetimes Explained

Master Rust's most unique concepts: ownership rules, mutable/immutable borrowing constraints, lifetime annotations. Compile-error examples + fixes to think like the Borrow Checker for safe zero-cost code.

1 min read
PostgreSQL Query Optimization Techniques

PostgreSQL Query Optimization Techniques

Master PostgreSQL optimization: EXPLAIN ANALYZE plans, choosing index types (B-tree/GIN/BRIN), updating statistics, tuning joins, and partitioned table design for maximum performance.

1 min read
Docker Compose Production Deployment Guide

Docker Compose Production Deployment Guide

Deep dive into Docker Compose production best practices: multi-stage builds, health checks, resource limits, logging, network isolation, and secrets management for reliable container deployments.

1 min read
Test Pyramid: Unit/Integration/E2E Ratios & Implementation

Test Pyramid: Unit/Integration/E2E Ratios & Implementation

Systematic test pyramid breakdown: bottom unit tests (many, fast, mock isolated), middle integration tests (real service/db/message interaction), top E2E tests (few, critical user flows). Recommended ratio 70/20/10, with coverage metrics and implementation playbook.

1 min read