第九章 k8s集群安全机制-认证2 核心笔记
1. kubeadm join 命令的双向认证机制
kubeadm join 命令用于将Node节点加入K8s集群，核心包含两个认证相关参数，实现双向身份验证：
--token：kubeadm集群为Node节点颁发的时效性令牌，作用是让API Server识别Node是否合法，类比帮派暗号，仅在有效期内生效，过期即失效。--cacert（CA证书哈希值）：作用是让Node验证API Server的合法性，防止Node接入错误的集群，类比帮主信物，双向验证通过后Node才能加入集群。
补充：Node加入集群时已完成双向证书认证，因此kubelet的证书可以由集群自动签发。
2. kubeconfig 文件详解
2.1 核心作用
kubeconfig是K8s集群认证的凭证封装文件，将访问API Server需要的所有参数（集群CA证书、API Server地址、客户端证书、私钥、用户标识、集群标识、上下文信息）整合到单个文件中，避免执行kubectl命令时重复添加大量参数。
2.2 默认配置与重要性
- 默认路径为
~/.kube/config，是管理员权限最高的集群访问凭证，必须妥善保管，禁止泄露。 - 安装完K8s集群后，通常会将
/etc/kubernetes/admin.conf拷贝到~/.kube/config，该文件就是管理员使用的kubeconfig文件。 - 若删除/移走该文件，
kubectl会默认尝试访问本地127.0.0.1:8080非安全端口，请求会被直接拒绝；放回文件后即可恢复正常访问。
2.3 文件核心字段解析
kubeconfig包含三类核心配置：
- clusters（集群配置）：存储集群的CA根证书、API Server访问地址、集群名称，用于验证API Server身份、定位集群。
- users（用户配置）：存储客户端证书、私钥、用户名称，用于向API Server证明自身身份。
- contexts（上下文配置）：关联集群和用户，切换上下文即可快速切换访问的集群和身份，通过
kubectl config use-context <上下文名称>即可完成切换。
3. 集群组件的认证规则
3.1 需要加密认证的组件
以下组件与API Server通信时需要完成双向证书认证：
- kubelet
- kube-proxy
- kubectl
3.2 无需加密认证的组件
以下组件默认与API Server部署在同一台Master节点，通过本地127.0.0.1非安全端口通信，无需额外加密：
- controller-manager
- scheduler
- cloud-controller-manager
3.3 证书颁发方式
- 自动颁发：仅kubelet适用，因为kubelet通过kubeadm join流程加入集群时已完成双向认证，集群信任其合法性，因此自动签发证书。
- 手动颁发：kube-proxy、kubectl、controller-manager、scheduler等组件适用，因为这些组件无法通过join流程自动验证合法性，需要管理员手动签发证书后封装到kubeconfig中使用。
4. Pod的认证方式：Service Account（SA）
4.1 为什么Pod不用证书认证
Pod是动态创建、销毁的资源，可能秒级扩缩容，若为每个Pod手动签发证书，成本极高，且证书泄露后安全风险大，因此K8s采用专门的Service Account实现Pod的认证。
4.2 Service Account 核心组成
Service Account是K8s内置的Secret资源类型，K8s的Secret分为两类：一类用于Service Account，另一类是Opaque类型，用于存储用户自定义的保密信息。每个SA对应3个核心文件，Pod使用SA时会自动挂载到/var/run/secrets/kubernetes.io/serviceaccount目录下：
- ca.crt（集群CA根证书）：Pod用该证书验证API Server返回的证书是否合法，确认API Server的身份，实现服务端身份验证。
- token（JWT令牌）：由API Server使用私钥签发的符合JWT（JSON Web Token）标准的字符串，用于API Server验证Pod的身份，确认Pod的合法性；JWT天生适用于分布式场景的单向身份认证，匹配Pod访问API Server、API Server不主动访问Pod的交互逻辑。
- namespace（命名空间文件）：存储Pod所属的命名空间名称，用于标识Pod的作用域，因为API Server是集群级别的，需要区分不同命名空间下同名Pod的权限（比如
ns1下的pod-a和ns2下的pod-a权限可能不同）。
4.3 默认行为与创建方式
- 每个命名空间默认自带一个名为
default的Service Account，Pod创建时如果不指定SA，会自动使用default SA，并自动挂载对应凭证。 - 自定义SA的创建非常简单，执行
kubectl create serviceaccount <SA名称>即可，集群会自动生成对应的Secret并关联到SA，无需手动配置证书、Token等参数。
AI 总结
本章节详细讲解了K8s集群的认证机制：整体分为集群组件认证和Pod认证两类。组件侧通过双向证书认证保障通信安全，kubelet因加入集群时已完成双向验证可自动签发证书，其余核心组件需管理员手动签发证书，凭证统一封装在kubeconfig文件中；Pod侧针对动态特性采用Service Account实现认证，SA由CA证书、JWT Token和命名空间信息组成，兼顾了安全性和灵活性，适配Pod秒级扩缩容的场景。