4. 节点扩容基础：节点注册流程、kubelet启动参数、节点身份认证机制
节点扩容是集群生命周期管理中最频繁的操作之一。从安全角度看，新节点加入集群的过程本质上是身份注册与凭证分发的过程。如果这一过程存在漏洞，攻击者可能通过伪造节点身份获取集群控制权。本节将深入剖析节点注册的完整流程、kubelet 的关键启动参数以及节点身份认证的核心机制。
4.1 节点注册流程：从引导到就绪
一个全新的节点（裸机或虚拟机）加入 Kubernetes 集群，通常经历以下四个阶段：
| 阶段 | 操作主体 | 安全要点 |
|---|---|---|
| 1. 引导（Bootstrap） | kubelet → API Server | 使用引导令牌（Bootstrap ）进行一次性身份验证 |
| 2. CSR 提交 | kubelet → API Server | 提交证书签名请求（CertificateSigningRequest），包含节点公钥 |
| 3. CSR 审批 | 集群管理员 / 控制器 | 自动或手动审批 CSR，确保节点身份真实 |
| 4. 证书分发与注册 | API Server → kubelet | 签署并下发节点证书，kubelet 使用该证书进行后续通信 |
4.2 kubelet 启动参数：安全配置清单
kubelet 是节点上的核心代理，其启动参数直接决定了节点的安全基线。以下是与节点注册和身份认证相关的关键参数：
| 参数 | 默认值 | 安全建议 |
|---|---|---|
--bootstrap-kubeconfig |
空 | 必须指定，指向包含引导令牌的 kubeconfig 文件 |
--kubeconfig |
空 | 节点注册成功后自动生成，用于后续通信 |
--cert-dir |
/var/lib/kubelet/pki |
确保目录权限为 700，仅 root 可读写 |
--rotate-certificates |
true |
启用证书自动轮换，降低私钥泄露风险 |
--rotate-server-certificates |
false |
启用 kubelet 服务端证书自动轮换（需 CSR 审批支持） |
--authentication--webhook |
false |
启用 TokenReview API 验证请求令牌，增强 API 安全 |
--authorization-mode |
AlwaysAllow |
生产环境应改为 Webhook，由 API Server 执行授权 |
--client-ca-file |
空 | 指定 CA 证书文件，用于验证 API Server 身份 |
--authentication--webhook=false 和 --authorization-mode=AlwaysAllow，这会导致 kubelet 不验证任何请求来源。生产环境中必须启用 Webhook 模式，否则任何能访问 kubelet 端口的进程都可以执行特权操作。
4.3 节点身份认证机制：证书与令牌
Kubernetes 节点与 API Server 之间的身份认证主要依赖两种机制：X.509 证书和引导令牌（Bootstrap ）。两者在节点生命周期中扮演不同角色。
4.3.1 X.509 证书认证
节点注册完成后，kubelet 使用由集群 CA 签署的客户端证书与 API Server 通信。证书中包含节点的身份信息（Common Name 通常为 system:node:<node-name>，Organization 为 system:nodes）。API Server 通过验证证书签名和 CN/O 字段来确认节点身份。
4.3.2 引导令牌认证
引导令牌是节点首次注册时使用的临时凭证。它本质上是一个 Secret 资源，存储在 kube-system 命名空间中。引导令牌的格式为 [a-z0-9]{6}.[a-z0-9]{16}，例如 07401b.f395accd7ae3b1c9。
| 特性 | X.509 证书 | 引导令牌 |
|---|---|---|
| 生命周期 | 长期（通常 1 年，可自动轮换） | 短期（默认 24 小时，建议更短） |
| 使用场景 | 节点注册后的所有通信 | 仅节点首次注册 |
| 存储位置 | 节点本地文件系统（/var/lib/kubelet/pki） |
集群 Secret（kube-system 命名空间） |
| 泄露影响 | 攻击者可伪装成该节点 | 攻击者可注册新节点 |
| 轮换方式 | 自动（--rotate-certificates） |
手动删除 Secret 或等待 TTL 过期 |
4.4 节点身份认证的 RBAC 绑定
节点注册完成后，kubelet 需要获得适当的 RBAC 权限才能正常工作。Kubernetes 通过 ClusterRoleBinding 将 system:nodes 组绑定到 system:node ClusterRole，从而赋予节点访问自身状态、Pod 等资源的权限。
# 查看 system:nodes 组的 ClusterRoleBinding
kubectl get clusterrolebinding system:node -o yaml
# 典型输出（简化）
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: system:node
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:node
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:nodes
system:node ClusterRole。如果需要为节点添加额外权限（例如访问特定 ConfigMap），应创建独立的 ClusterRole 并通过节点标签选择器进行绑定，避免权限过度扩散。
4.5 节点扩容安全配置清单
在实施节点扩容前，请对照以下清单进行安全配置检查：
- 引导令牌管理： 使用
kubeadm create --ttl 1h创建短期令牌，避免使用默认的 24 小时 TTL。 - kubelet 参数加固： 确保
--authentication--webhook=true和--authorization-mode=Webhook已启用。 - 证书目录权限：
/var/lib/kubelet/pki目录权限应为 700，所有证书文件权限应为 600。 - CSR 自动审批策略： 配置
kube-controller-manager的--cluster-signing-cert-file和--cluster-signing-key-file，并启用 CSR 自动审批。 - 节点身份白名单： 在云环境或受控网络中，使用
NodeRestriction准入控制器限制节点只能修改自身的标签和注解。 - 审计日志： 启用 API Server 的审计日志，记录所有节点注册和 CSR 审批事件。