Kubernetes 1.34/1.35证书革命：从手动地狱到零信任天堂

Shengxu included in Kubernetes Cloud Security News

2026-01-03 About 700 words 3 minutes

Contents

最近升级到1.35，发现证书管理的变化堪称革命性——特别是对自管K8s用户来说，运维负担直接腰斩。

过去证书问题是安全事件的"隐形杀手"：过期中断、token泄露、手动轮转占运维30%时间。1.34/1.35带来原生自动化mTLS，让零信任不再是Istio的专利。今天咱们聊聊这些新特性，然后按自管K8s vs 云K8s实战对比。

Kubernetes 1.34：Pod Certificates（Alpha → Beta）

一句话概括：Pod像人一样自动申请"身份证"，小时级短活证书，mTLS零sidecar。

核心机制

graph LR
    A[Pod启动] --> B[kubelet生成CSR]
    B --> C[API Server签发]
    C --> D[自动mount /run/workload-spiffe-credentials]

graph LR
    A[Pod启动] --> B[kubelet生成CSR]
    B --> C[API Server签发]
    C --> D[自动mount /run/workload-spiffe-credentials]

graph LR
    A[Pod启动] --> B[kubelet生成CSR]
    B --> C[API Server签发]
    C --> D[自动mount /run/workload-spiffe-credentials]

实战：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71


apiVersion: apps/v1
kind: Deployment
meta
  name: qwen-72b-secure
  labels:
    app: qwen-72b
    security: zero-trust 
spec:
  replicas: 1
  selector:
    matchLabels:
      app: qwen-72b
  template:
    meta
      labels:
        app: qwen-72b
    spec:
      serviceAccountName: llm-inference-sa
      nodeSelector:
        node.kubernetes.io/instance-type: "g5.12xlarge"
      
      containers:
      - name: vllm-server
        image: vllm/vllm-openai:v0.9.1
        
        # === 应用直接消费证书 ===
        # vLLM 原生支持 HTTPS，直接指向自动挂载的路径
        command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]
        args:
          - "--model=/data/models/Qwen-72B-Int4"
          - "--tensor-parallel-size=4"
          - "--gpu-memory-utilization=0.92"
          # 🔐 开启 mTLS/HTTPS 
          # 使用 Pod Certificates 自动生成的证书文件
          - "--ssl-certfile=/run/workload-spiffe-credentials/tls.crt"
          - "--ssl-keyfile=/run/workload-spiffe-credentials/tls.key"
        
        ports:
        - containerPort: 8000
          name: https # 标记为 HTTPS 端口
        
        resources:
          limits:
            nvidia.com/gpu: "4"
        
        volumeMounts:
        # === 1.35 标准挂载路径 ===
        # 挂载到 SPIFFE 标准位置，无需 Sidecar 注入
        - mountPath: /run/workload-spiffe-credentials
          name: pod-identity-cert
          readOnly: true
        - mountPath: /data/models
          name: model-storage

      volumes:
      - name: model-storage
        persistentVolumeClaim:
          claimName: qwen-models-pvc
      
      # === 1.35 PodCertificate 卷声明 ===
      - name: pod-identity-cert
        projected:
          sources:
          - podCertificate:
              # 关键：指定 Signer (EKS/Cloud 环境通常有专用 Signer)
              # 如果是自建 K8s，可使用 internal-ca 或 kubernetes.io/kube-apiserver-client
              signerName: "eks.amazonaws.com/pod-ca" 
              
              # 关键：自定义证书有效期 (1.35 Alpha/Beta 特性)
              # 强制 1 小时轮转
              expirationSeconds: 3600 

1.34独占特性：

Kubelet server证书自动轮转：--rotate-certificates默认开启，节点证书永不过期。
弃用弱TLS cipher：防POODLE攻击，强制现代加密套件。
ImagePullSecrets OIDC化：ECR拉取实现零静态token。

Kubernetes 1.35：安全再升级（Beta稳定+新Alpha）

一句话概括：证书验证从严，防冒充+自动化续约成标配。

新增杀手锏

KubeletCertCNValidation (Alpha): API Server强制验证证书 CN = 节点hostname，而非仅IP。
- 场景：ARP欺骗攻击终结者，EKS多租户环境必备。
PodCertificates spec.userConfig: 自定义SAN、KeyUsage，更灵活对接企业CA。
kubeadm upgrade集成renew: 升级时自动备份并续约控制平面证书。

1.35 验证CN防护命令

1

kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.conditions[?(@.type=="KubeletCNValid")].status}{"\n"}{end}'

⚠️ 容易踩坑的限制条件

在生产环境部署前，请务必注意：

证书生命周期固定：默认 TTL 1小时。长连接应用需自行处理重连。
私钥不离节点：kubelet 生成的私钥仅存在内存/临时盘，Pod 无法导出。
Signer 限制：目前主要支持集群内置 Signer，对接外部 PKI 仍需 cert-manager 桥接。

自管K8s vs 云K8s：痛点→解法实战对比

1. 自管K8s（kubeadm/kops）：从地狱到自动化

更新前：100节点集群，证书过期中断5%，每月手动renew 1-2天。

更新后：

1
2
3
4


# 开启 Feature Gates
kubeadm init --feature-gates=PodCertificates=true,KubeletCertCNValidation=true
# 升级自动续约
kubeadm upgrade plan v1.35 --certificate-renewal=true

自管收益矩阵：

痛点	老方案	新方案 (1.35)	ROI
手动renew	`kubeadm certs` 每月	kubelet auto-rotate	MTTR 15min → 0min
无mTLS	Istio sidecar	PodCertificates 原生	CPU 省 10%
Token泄露	永不过期 SA token	小时级 TTL 证书	安全事件降 80%

自管迁移 Trap：自建CA需在 ca-config.json 中显式支持 pod profile。

2. 云K8s（EKS/AKS/GKE）：开箱即用加速器

EKS前：控制平面托管好，但节点cert仍手动，Fargate无kubelet问题。

EKS 1.35 升级实战（修正步骤）：

控制台操作：EKS Console → Cluster → Update → Version 1.35。

开启特性（EKS 需显式启用）：

1
2


# 必须更新 API Server 配置以启用 Alpha/Beta 特性
kubectl patch cm kube-apiserver -n kube-system -p '{"data":{"featureGates":"PodCertificates=true,KubeletCertCNValidation=true"}}'

节点组轮转：

1

aws eks update-nodegroup-version --cluster-name my-cluster --nodegroup-name gpu-nodes

云厂商支持对比：

厂商	开通难度	独特优势
EKS	⭐⭐	Bedrock mTLS + KMS 原生集成
AKS	⭐⭐⭐	AAD 无缝集成，零信任企业级支持
GKE	⭐	Workload Identity 增强

详细成本对比表 (Updated)

方案	软件授权	CPU 开销	存储成本	运维时间	总成本/年 (100节点)
cert-manager	$0 (开源)	2-4 vCPU	3GB+	~120h	$12,000
Istio mTLS	License/Ent	10-15%	5GB+	~60h	$25,000+
K8s 1.35 原生	$0	<0.5%	<100MB	~10h	$2,500

迁移全攻略：零中断路线图

迁移前置检查清单 (Checklist)

CA 兼容性：确认 Cluster CA 支持签发 Client Auth 证书。
节点主机名：运行 openssl x509 -in /etc/kubernetes/pki/kubelet.crt -text | grep CN 确保 CN 与 Hostname 一致。
API 版本：扫描所有 manifest，移除旧版 certificates.k8s.io/v1beta1 引用。

通用步骤

Week 1: kube-score + 证书过期扫描。
Week 2: Canary 10% 节点升级，开启 Metrics 监控。
Week 3: 全量 Feature Gates，kubectl 测试 Pod 签发。
Week 4: 关闭旧 ServiceAccount Token 挂载，切换全 mTLS。

EKS + Bedrock 推荐路线

阶段1: EKS 1.34 → 启用 PodCertificates + ImagePullSecrets OIDC。
阶段2: 1.35 → 开启 Kubelet CN 验证 + DRA GPU 调度。
阶段3: Bedrock Agent 全 mTLS，配置 Transit Gateway 安全组。

验证命令：

1
2


kubectl get pods -l app=llm -o yaml | grep podCertificate
kubectl exec -it qwen-inference -- openssl x509 -in /run/workload-spiffe-credentials/tls.crt -text

结语：2026 K8s 安全新基线

1.34/1.35 证书特性让 Kubernetes 从"容器编排器"真正进化成 AI 原生基础设施。对我的 EKS+Bedrock 栈而言，PodCertificates+mTLS 直接让 RAG 系统安全系数翻倍。

强烈推荐：测试环境立即 1.35，生产蓝绿跟进。

参考资料

https://kubernetes.io/blog/2025/08/27/kubernetes-v1-34-release/
https://kubernetes.io/blog/2025/12/17/kubernetes-v1-35-release/
https://github.com/kubernetes/enhancements/issues/4317
https://aws.github.io/aws-eks-best-practices/security/docs/

Updated on 2026-01-18 with latest 1.35 GA details.