Kubernetes 访问控制全解析：认证、RBAC 与准入控制一次搞懂 实战指南

Kubernetes 访问控制全解析：认证、RBAC 与准入控制一次搞懂 实战指南Kubernetes 访问控制是保障集群安全的核心防线。无论是普通用户、ServiceAccount，还是 Pod 自身与 API Server 的交互，都会经过认证 → 授权 → 准入控制三层检查。本文将深入每一层的原理与配置，并通过大量实战示例，让你彻底掌握 Kubernetes 访问控制。1. 访问控制三层架构一个请求到达 API Server 后，会经历以下流程：客户端请求 → 认证（Authentication） → 授权（Authorization） → 准入控制（Admission Control） → etcd认证：确认“你是谁”（身份）。授权：确认“你能做什么”（权限）。准入控制：在对象持久化之前，对其进行校验或修改（策略增强）。注意：匿名请求和 ServiceAccount 也经过相同流程，只是身份来源不同。2. 认证（Authentication）K8s 没有内部用户存储，用户由外部系统管理（如证书、OIDC、Webhook）。API Server 支持多种认证方式，按顺序尝试，直到有一个成功。2.1 认证方式概览认证方式典型用途说明X509 客户端证书管理员、kubelet最常用，CN 为用户名，O 为组静态 Token 文件测试、遗留系统用 CSV 文件存储 token，不推荐生产引导令牌（Bootstrap Token）节点加入集群用于 kubeadm 自动颁发证书ServiceAccount 令牌Pod 内访问 APIJWT 令牌，自动挂载OIDC企业 SSO与 Dex、Keycloak 等集成Webhook Token自定义认证请求外部服务验证 token匿名请求允许未认证访问需显式启用并授权2.2 核心概念：用户与组普通用户：由外部管理，无法通过 K8s API 增删改。ServiceAccount：由 K8s 管理，存在 Namespace 中，用于 Pod 内进程。组：可以是证书中的 O 字段、OIDC 中的 group 声明或静态 token 中的组。2.3 实战：创建客户端证书用户目标：生成一个名为john的用户证书，并为其配置 kubeconfig，使其能够访问集群。# 1. 生成私钥 openssl genrsa -out john.key 2048 # 2. 生成证书签名请求（CN=用户名，O=组，O 可选） openssl req -new -key john.key -out john.csr -subj "/CN=john/O=dev-team" # 3. 使用集群 CA 签发证书 openssl x509 -req -in john.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out john.crt -days 365 # 4. 设置 kubeconfig 条目 kubectl config set-credentials john --client-certificate=john.crt --client-key=john.key kubectl config set-context john@kubernetes --cluster=kubernetes --user=john生产环境应使用更安全的证书管理方案，如cfssl或cert-manager。3. 授权（Authorization）认证通过后，请求进入授权层。K8s 支持多种授权模块，RBAC是生产标准。3.1 RBAC 对象对象作用域用途RoleNamespace授予某命名空间内的资源权限ClusterRole集群授予集群级资源权限，或跨 Namespace 复用RoleBindingNamespace将 Role/ClusterRole 绑定到 Subjects，仅影响该命名空间ClusterRoleBinding集群将 ClusterRole 绑定到 Subjects，影响整个集群Subjects：可以是 User、Group、ServiceAccount。3.2 RBAC 核心规则：资源与动词apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default na