在 Ubuntu 上配置 Kubernetes 认证
一 认证方式与总体架构
- Kubernetes 对每个请求依次进行认证、授权、准入控制;所有组件与用户都经由 API Server 的 6443 端口进行通信。常见认证方式包括:
- 基于证书的 x509 客户端认证(配合 kubeconfig);
- ServiceAccount Token(挂载到 Pod 内供应用调用 API);
- 外部 OIDC 身份提供者(如企业 IdP);
- 旧式的 Token 与已废弃的 Basic Auth。生产环境推荐启用 TLS 双向认证 并使用 RBAC 做授权。
二 使用 kubeconfig 的 x509 客户端证书认证(管理员与用户)
- 准备证书与 kubeconfig(示例为 admin 用户):
- 生成客户端密钥与 CSR(CN 建议使用可辨识的用户名,例如 CN=admin):
openssl genrsa -out admin.key 2048
openssl req -new -key admin.key -out admin.csr -subj “/CN=admin”
- 使用集群 CA 签发客户端证书(假设 CA 证书与私钥为 /etc/kubernetes/pki/ca.crt 与 /etc/kubernetes/pki/ca.key):
openssl x509 -req -in admin.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out admin.crt -days 365
- 生成 kubeconfig(或编辑现有配置):
kubectl config set-cluster k8s-prod
–certificate-authority=/etc/kubernetes/pki/ca.crt
–embed-certs=true
–server=https://<APISERVER_IP>:6443
kubectl config set-credentials admin
–client-certificate=admin.crt
–client-key=admin.key
–embed-certs=true
kubectl config set-context admin@k8s-prod
–cluster=k8s-prod --user=admin
kubectl config use-context admin@k8s-prod
- 验证:
kubectl cluster-info
kubectl get nodes
- 说明:kubeconfig 包含 clusters、users、contexts 三部分;也可将证书内容以 certificate-authority-data / client-certificate-data / client-key-data 的 Base64 形式内嵌到 kubeconfig 中,便于分发。
三 为集群组件与 kubelet 配置客户端证书
- 组件到 API Server 的访问应全部使用 TLS 客户端证书 进行双向认证(示例为 Controller Manager 与 Scheduler):
- 生成客户端证书(CN 可使用组件名,例如 CN=system:kube-controller-manager):
openssl genrsa -out cs_client.key 2048
openssl req -new -key cs_client.key -out cs_client.csr -subj “/CN=system:kube-controller-manager”
openssl x509 -req -in cs_client.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out cs_client.crt -days 365
- 创建组件专用 kubeconfig(/etc/kubernetes/cmkubeconfig):
apiVersion: v1
kind: Config
clusters:
- name: local
cluster:
certificate-authority: /etc/kubernetes/pki/ca.crt
server: https://<APISERVER_IP>:6443
users:
- name: controllermanager
user:
client-certificate: /path/to/cs_client.crt
client-key: /path/to/cs_client.key
contexts:
- context:
cluster: local
user: controllermanager
name: cm-context
current-context: cm-context
- 配置组件启动参数使用 kubeconfig(以 systemd 环境为例,在对应的 drop-in 或环境文件中设置):
–kubeconfig=/etc/kubernetes/cmkubeconfig
同时确保 API Server 启用客户端证书校验(见下一节)。
- 对 kubelet 执行同类操作:为每个节点生成客户端证书(CN 通常为 system:node:<NODE_NAME>),并在 kubelet 配置或 kubeconfig 中指定 client-certificate / client-key 与 server 地址,然后重启 kubelet。
四 启用 API Server 双向认证与常用开关
- 在 kube-apiserver 启动参数中启用 TLS 与 客户端证书校验,并关闭不安全端口:
–secure-port=6443
–tls-cert-file=/etc/kubernetes/pki/apiserver.crt
–tls-private-key-file=/etc/kubernetes/pki/apiserver.key
–client-ca-file=/etc/kubernetes/pki/ca.crt
–anonymous-auth=false # 禁止匿名访问
–insecure-port=0 # 关闭 8080 明文端口
- 如集群使用 ServiceAccount,确保为控制器管理器提供 service-account-private-key-file 与 root-ca-file,以便签发与校验 ServiceAccount Token:
–service-account-private-key-file=/etc/kubernetes/pki/sa.key
–root-ca-file=/etc/kubernetes/pki/ca.crt
- 修改后重启 kube-apiserver 并验证:
curl https://<APISERVER_IP>:6443/api/v1/nodes
–cert /path/to/client.crt --key /path/to/client.key --cacert /etc/kubernetes/pki/ca.crt
五 常见问题与排查要点
- 证书不被信任:确保客户端证书由集群 CA 签发,kubeconfig 中的 certificate-authority 或 certificate-authority-data 正确;必要时使用 –embed-certs=true。
- 访问被拒绝但证书无误:检查 RBAC 绑定(例如 ClusterRoleBinding 是否授予了对应 Group/User 权限);证书 CN 与 RBAC 中的主体需匹配。
- 组件无法连接 API Server:确认组件 kubeconfig 路径、证书与私钥权限正确,且 API Server 已启用 –client-ca-file 与 –anonymous-auth=false。
- 使用旧版 kubeadm 静态 Pod 清单时,注意同时更新 /etc/kubernetes/manifests/kube-apiserver.yaml 中的相关参数并重启 kubelet 使清单生效。