Kubernetes集群多证书的安全作用及相关技术问询

一个Kubernetes集群包含kubelet、etcd、api-server等多个核心组件，搭建过程中需要配置大量证书与密钥，用于组件间的身份验证与加密通信。

从kubectl describe pod kube-apiserver-controlplane -n=kube-system的输出可以看到，API Server依赖多个证书文件实现与其他组件的安全通信：

> kubectl describe pod kube-apiserver-controlplane -n=kube-system

Name:                 kube-apiserver-controlplane
Namespace:            kube-system
...
Controlled By:  Node/controlplane
Containers:
  kube-apiserver:
    Container ID:  docker://6974d026de0b2fadb3d2628d0df971ddc4c3d772665b2cd960a1d0e385f97a5d
    Image:         k8s.gcr.io/kube-apiserver:v1.20.0
    Image ID:      docker-pullable://k8s.gcr.io/kube-apiserver@sha256:8b8125d7a6e4225b08f04f65ca947b27d0cc86380bf09fab890cc80408230114
    Command:
      kube-apiserver
      ...
      --client-ca-file=/etc/kubernetes/pki/ca.crt
      --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
      --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
      --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
      --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
      --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
      --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
      --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
      --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
      --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
      ...

核心疑问解答：证书的安全价值 #

你提到“黑客获取节点root权限即可拿到证书，复杂度未提升安全性”，这里需要明确：证书防护的是未获取节点权限时的网络攻击，以及节点间的横向渗透风险：

• 即使攻击者能接入集群内部网络，没有合法签名的证书，也无法冒充组件发起通信；
• 不同组件的证书权限粒度不同（比如kubelet证书仅能用于与API Server交互，无法直接访问etcd），即使某节点证书泄露，攻击者的攻击范围也会被限制，避免单点沦陷导致整个集群失控。

技术问题解答 #

1. Kubernetes集群面临的最主要（常见）安全风险 #

• 组件间通信窃听与篡改：控制平面组件传递集群配置、调度指令、密钥等敏感数据，未加密通信易被窃听或篡改；
• 未授权组件访问：恶意进程伪装成合法组件（如kubelet）向API Server发送请求，或非法访问etcd窃取集群核心数据；
• 节点横向渗透：单个节点被攻陷后，攻击者利用未受保护的内部通信，快速扩散至其他节点或核心组件；
• 容器逃逸：恶意容器突破隔离获取节点权限，进而利用内部通信漏洞攻击集群控制平面；
• 配置泄露：错误的组件权限配置、未加密的敏感存储，导致攻击者直接获取集群控制权。

2. 无证书保护时的攻击方式，以及与AWS LB-EC2通信的差异 #

无证书时的攻击路径

• 窃听攻击：通过抓包获取组件间的敏感通信内容，比如API Server与etcd的交互数据、kubelet的身份令牌；
• 中间人攻击：拦截并篡改通信数据包，比如伪造API Server指令让kubelet执行恶意操作，或修改etcd中的集群配置；
• 身份冒充：无需验证即可伪装成任意合法组件（如冒充API Server向etcd写入恶意数据，或伪装kubelet向集群注册恶意节点）；
• 数据篡改：直接修改未加密的通信内容，比如篡改Pod调度规则，将恶意容器部署至核心节点。

AWS LB与EC2无需HTTPS的原因

两者的差异核心在于环境信任模型与通信内容敏感度：

• 网络隔离强度：AWS LB与EC2的通信处于VPC内部，AWS提供了安全组、网络ACL等底层网络防护，网络边界清晰且可控；而Kubernetes集群可能运行在混合云、私有云或裸机环境，网络边界更模糊，组件分布更分散；
• 通信内容敏感度：AWS LB与EC2之间多为业务流量，而Kubernetes组件间是控制平面流量，包含集群的核心配置、认证信息等，一旦被篡改或窃听，直接影响整个集群的控制权；
• 身份验证机制：AWS服务依赖IAM角色实现身份授权，而Kubernetes组件分布在不同节点，需要通过mTLS实现双向身份验证，确保每个组件的合法性，而非依赖单一的网络层防护。

内容的提问来源于stack exchange，提问作者Ryan Lyu