K8s访问控制全解析：认证、授权与RBAC实战

k8s 里最容易绕晕的不是 Deployment，不是 Service，而是“谁能访问 API Server、能干什么”。我做过不少集群，第一次被权限问题卡了几个小时，也见过生产环境里因为权限过大留下的隐患。这篇就专门把 k8s 访问控制这条链路彻底盘清楚：认证怎么过、授权怎么配、权限模型怎么玩，以及实战里最常见的坑。如果你是刚把集群搭起来、正准备接入 CI/CD 或给同事开权限的，这篇正好对症。

1. 先从整体上理解 k8s 的访问控制链路

1.1 三个关卡：认证、授权、准入

Kubernetes 对 API Server 的所有请求，都要经过一个固定顺序的关卡链，逃不掉。完整顺序是：认证（Authentication）→ 授权（Authorization）→ 准入控制（Admission Control）。

认证要回答“你是谁”。请求到达 API Server 之后，第一步就是验证身份。这部分工作由 API Server 内嵌的认证模块完成。支持的方式很多：客户端证书、Bearer Token、ServiceAccount Token、基本的用户名密码、Webhook 回调等等。只要其中任何一种验证通过，请求就带着“身份信息”进入下一关。

授权要回答“你能干什么”。身份验证通过不代表就能为所欲为。RBAC 模块会拿着请求里的用户信息，去匹配你绑定的角色，判断你对某个资源（比如 Pod、Deployment）有没有执行某个操作（比如 get、create、delete）的权限。这一步在认证之后、准入之前执行。

准入控制管的是“即使你有权限，也要再检查一遍”。它更像一个策略层，比如强制打标签、校验镜像来源、限制资源配额等等。这类控制器可以修改或拒绝请求，很多业务侧的合规要求都会放在这一层实现。

理解这条链路之后，排查问题就顺手多了：先看认证有没有过，再看授权有没有配。很多同学一上来就去翻 RBAC，结果问题其实是证书过期或 kubeconfig 里的用户写错了，白费力气。

1.2 为什么这种分段设计是合理的

一开始接触这多模块，可能觉得繁琐。但拆成三步其实是刻意的设计，让每一种诉求都有了明确的落点。

比如，你想让某个用户只能看 Pod 但不能删 Pod，那就只改授权层；想让某台构建机器用 Token 登录但不能用证书，那就只配置认证层；想全局禁止创建带有特权容器的 Pod，那就放在准入层。各层职责单一、互不干扰，出了问题也容易定位。

同时，这种设计还让“账号体系”和“权限体系”解耦。一个用户可以被授予多个角色，一个角色也可以被多个用户使用。授权规则可以独立演进，不用动认证结构。规模上来之后，权限治理可以用 Git 管理、走评审流程，靠的就是这种解耦。

1.3 先说清楚 User 和 ServiceAccount 的区别

k8s 里的“身份”分为两大类：一种是人类用户，另一种是 Pod 里跑程序用的 ServiceAccount。这两者经常被搞混。

人类用户，比如管理员、开发者、审计员，Kubernetes 本身不维护这类用户的对象，它们存在于外部体系，比如证书里的 CN 字段、私有的用户数据库、云厂商的 IAM 等等。API Server 只认请求里携带的身份凭证，验证通过后就把请求者当作某个 User 来处理。

ServiceAccount 则不同，它是 k8s 里的 API 对象，专门给 Pod 里的进程用的身份。它对应一把密钥，通常以 Secret 的形式挂载到 Pod 里，Pod 里的应用通过这个凭证访问 API Server。比如你在 Pod 里用客户端库查询 Pod 列表，用的就是这种身份。

权限配置的时候必须分清楚：给“人”授什么权，给“程序”授什么权。不能图省事直接给某个 ServiceAccount 绑定一个超级权限，否则一旦 Pod 被攻破，攻击者就拿到了集群的管理权，后果很难收拾。

2. 认证层核心机制实操详解

2.1 客户端证书认证：最基础也最常用

客户端证书是 k8s 最常见的认证方式。kubeadm 部署的集群，管理员 kubeconfig 里用的就是客户端证书认证。原理很简单：CA 签发给你的证书里有 CN（Common Name）和 O（Organization）字段，API Server 验证证书有效后，把 CN 当作用户名、O 当作用户组。

自己签发客户端证书，步骤一般是这样的：先为客户端生成私钥，再生成证书签名请求，然后用集群 CA 签署，最后把证书和私钥放回 kubeconfig 里。

我用一个实际例子说明。假设要为某开发者签发证书：

# 第一步：为开发者生成私钥 openssl genrsa -out dev.key 2048 # 第二步：创建 CSR，其中 CN 是用户名，O 是用户组 openssl req -new -key dev.key -out dev.csr -subj "/CN=dev-user/O=developers" # 第三步：用集群 CA 签署证书 # 这里假设集群 CA 是 /etc/kubernetes/pki/ca.crt 和 ca.key sudo openssl x509 -req -in dev.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out dev.crt -days 365

签发完证书之后，把它写进 kubeconfig：

kubectl config set-credentials dev-user --client-certificate=/path/to/dev.crt --client-key=/path/to/dev.key

这里有个容易踩的坑：CN 写什么，用户名就是什么，RBAC 里绑定的也是这个名字，两者必须保持一致，否则授权永远匹配不上。

注意：用 CA 私钥签发证书的操作在生产环境是一项高危动作，建议通过更安全的签发流程管理，不要让普通成员接触到 CA 私钥。

2.2 ServiceAccount 与 Token 认证

大多数集群内的自动化操作都走 ServiceAccount + Token 这条链路。Kubernetes 会为每个 ServiceAccount 自动生成长期可用的 Token，存放在同名 Secret 里，Pod 创建时可以指定挂载这个 Secret 到/var/run/secrets/kubernetes.io/serviceaccount/目录。

Token 里包含了这个 ServiceAccount 的名称和所属命名空间，API Server 把它解析出来之后，就以这个身份继续走 RBAC 授权。

创建 ServiceAccount 并查看 Token：

# 创建 ServiceAccount kubectl create serviceaccount ci-builder -n ci # 查看对应的 Secret kubectl get secret -n ci

新版 Kubernetes 对 Secret 的处理方式有所调整，但原理不变：Token 就是一串由集群 CA 签发的凭证，Pod 拿着它就能请求 API。

实际操作中，我更推荐给 Pod 显式声明 ServiceAccount 名称，而不是用默认的 default，因为默认的往往权限给多了或给少了，都不利于最小化授权。在 Deployment 里指定：

apiVersion: apps/v1 kind: Deployment metadata: name: my-app namespace: ci spec: template: spec: serviceAccountName: ci-builder

2.3 kubeconfig 里藏着哪些认证细节

kubeconfig 可以理解为 kubectl 的配置文件，里面保存了访问集群所需的地址、CA 证书、客户端凭证等信息。默认路径是~/.kube/config。

一个标准的多集群 kubeconfig 往往包含若干个 context，每个 context 由 cluster、user、namespace 三段组合而成。切换集群本质上是切换 context：

kubectl config get-contexts kubectl config use-context prod-cluster

排错时最常碰到的“没有权限”问题，极大概率是当前 context 指向了另一个集群或另一个用户。拿到一个报错，先kubectl config current-context确认自己在哪里，再检查 RBAC。

2.4 认证优先级：多个认证方式并存时按什么顺序执行

API Server 可以同时启用多种认证器。比如集群同时启用客户端证书和 Token，某个请求到底用哪个身份？这就要了解“第一成功优先”原则：API Server 按启用顺序逐个尝试，一旦某个认证器验证通过，就不再往后走。

这种设计在混合场景下很有用。比如管理员用证书，CI 系统用 Token，普通用户通过 OIDC 登录，它们可以同时存在，互不冲突。

但也带来一个隐蔽问题：如果 Token 认证模块排在证书认证前面，而某个 Token 恰好是某个用户的，那么此人即使提供了合法证书，最终生效的也是 Token 身份。所以生产环境通常明确各种认证器的顺序，避免身份混淆。

2.5 认证排错：403 和 401 到底差在哪

很多同学对 401 和 403 分不清楚。401 表示“未认证”，也就是请求根本没有通过认证环节，API Server 不知道你是谁；403 表示“已认证但没权限”，也就是身份验证通过了，但授权环节拒绝了你的请求。

换句话说：401 是“你没带身份证”，403 是“带了身份证但不让你进”。看报错先分清楚是哪一种，再决定排查方向。如果是 401，重点检查证书、Token、kubeconfig；如果是 403，重点检查 RBAC 里有没有绑定对应的角色。

实战里经常遇到的情况是：账号确实创建了，也绑定了角色，但就是 403。这时候多半是认证身份和授权角色对不上。比如证书里 CN 写的是dev-user，RBAC 里绑定的却是dev_user，一字之差，权限永远匹配不上。

3. RBAC 授权模型全解析

3.1 四类核心对象之间的关系

RBAC（基于角色的访问控制）是 Kubernetes 默认启用且最常用的授权模式。核心对象有四个：Role、ClusterRole、RoleBinding、ClusterRoleBinding。

Role 是命名空间级别的角色，定义了一组规则，比如“在 default 命名空间里可以 get Pod”。ClusterRole 是集群级别的角色，可以定义集群范围的规则，比如“可以查看所有命名空间的节点”“可以查看所有命名空间的 Pod”。

RoleBinding 把 Role 绑定到一个用户或 ServiceAccount，作用范围限定在某个命名空间。ClusterRoleBinding 把 ClusterRole 绑定到用户或 ServiceAccount，作用范围是整个集群。

这里必须强调一点：RoleBinding 可以引用 ClusterRole。这是最常用的组合方式，因为你可以复用一套集群级的通用角色，把它绑定到某个命名空间里的用户。绑定之后，这个用户只在那个命名空间内拥有对应权限，不会扩散到整个集群。

用一张表概括：

3.2 Role 与 ClusterRole 的规则写法

RBAC 规则本质上是“允许某人对某类资源执行某些操作”，不支持的场景是不存在“拒绝”规则的，只有“允许”和“不允许（默认拒绝）”。这一点跟防火墙的默认策略正好相反，要特别留意。

一个简单的 Role 示例：

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: dev name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"]

这里的 apiGroups 是 API 组名。核心资源（Pod、Service、ConfigMap 等）属于空字符串组，写作""；Deployment、Ingress 等属于apps组；NetworkPolicy 属于networking.k8s.io组。搞错组名是新手高频错误之一，写成了apps却拿它配 Pod，规则永远不会生效。

resources 是资源类型，注意区分“资源”和“子资源”（subresource）。比如 Pod 的状态、日志就属于子资源，很多权限问题都出在这里：你给了 Pod 的 get 权限，却没有给 pods/log 的 get 权限，kubectl logs就会报权限不足。

一个更完整、贴近实际生产场景的规则写法：

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: dev name: app-operator rules: - apiGroups: [""] resources: ["pods", "services", "configmaps", "secrets"] verbs: ["get", "list", "watch"] - apiGroups: ["apps"] resources: ["deployments", "statefulsets"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] - apiGroups: [""] resources: ["pods/log"] verbs: ["get", "list", "watch"]

3.3 RoleBinding 和 ClusterRoleBinding 的绑定写法

RoleBinding 的典型写法如下：

apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: dev name: dev-user-pod-reader subjects: - kind: User name: dev-user apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io

subjects 里可以绑定 User、Group 或 ServiceAccount。绑定 ServiceAccount 时要特别注意命名空间字段，因为 ServiceAccount 本身是有命名空间属性的，不写的话默认是 default。我见过有人想在 ci 命名空间绑定 ci-builder，结果忘了写 namespace，绑定到了 default 里的同名账号，权限始终不生效。

ClusterRoleBinding 的写法类似，区别只在 kind 和 metadata 上没有 namespace（ClusterRoleBinding 是集群级资源）。

3.4 聚合角色：把多个规则拼成一个大角色

在 k8s 1.9 之后，支持了聚合 ClusterRole 的功能。简单说，你可以定义一个大角色，通过 labelSelector 把多个 ClusterRole 的规则聚合到一起。

举个例子，想定义一个“可读全部核心资源”的角色，同时允许其他团队通过打标签的方式扩展这个角色的能力：

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: aggregate-reader labels: rbac.example.com/aggregate-to: "reader" aggregationRule: clusterRoleSelectors: - matchLabels: rbac.example.com/aggregate-to: "reader" rules: []

之后任何 ClusterRole 只要打上rbac.example.com/aggregate-to: "reader"标签，它的规则就会自动合并进 aggregate-reader。这个模式适配插件化、模块化的权限治理，但建议在规模需求明确之后再考虑，不要为了“炫技”把权限体系搞得过于复杂。

3.5 默认的 ClusterRole 有什么坑

Kubernetes 自带了一组默认 ClusterRole，比如 cluster-admin、admin、edit、view。它们解决的是大部分常见场景，但也埋着不少坑。

最典型的是 view 角色并不能查看所有东西。它允许查看大多数资源，但 Secret 这类敏感资源明确排除在外，因为 k8s 认为即使只读，也不能暴露给所有普通用户。

admin 角色可以在一个命名空间里管理大部分资源，包括 Role 和 RoleBinding。注意，admin 不包含对 ResourceQuota 的管理权限，而且它能管理角色绑定的设计，实际上给了用户“间接提权”的可能。如果一个用户拥有 admin 权限，他完全可以把 cluster-admin 绑定给自己。所以“给 admin 就是给半个集群”这句话在某些场景下不是开玩笑。

cluster-admin 是真正的超级权限，可以操作集群内的一切资源，包括 CRD。生产环境里绑定 cluster-admin 给普通用户或外部系统，应当有非常充分的理由并经过严格审批。

4. 实战：从零创建一个“只有查看权限”的账号

4.1 设计思路与需求梳理

先模拟一个场景：某公司来了一个数据分析师，他需要在某个命名空间里查看 Pod、Service、ConfigMap 的实时状态，但绝对不能有修改和删除权限，也不需要看 Secret。这个场景在数据平台、业务运营场景里非常常见。

权限拆解下来就三条：

• 能获取 Pod、Service、ConfigMap 列表
• 能实时查看 Pod 日志（数据分析经常要看日志）
• 不能读 Secret，不能修改和删除任何资源

这里有个细节要注意：数据分析师如果需要看 Pod 日志，就必须有pods/log子资源的 get 权限，否则kubectl logs会直接报权限不足。这是初配权限时最容易漏的。

4.2 完整创建过程（含 YAML 文件）

第一步，创建命名空间和角色。这里在>apiVersion: v1 kind: Namespace metadata: name:>openssl genrsa -out analyst.key 2048 openssl req -new -key analyst.key -out analyst.csr -subj "/CN=analyst/O=data-team"

然后使用集群 CA 签发证书（前提是你有 CA 私钥访问权限）：

sudo openssl x509 -req -in analyst.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out analyst.crt -days 365

第三步，创建 RoleBinding，把只读角色绑定给 analyst：

apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace:>kubectl config set-cluster prod-cluster --server=https://<api-server-address>:6443 --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true kubectl config set-credentials analyst --client-certificate=analyst.crt --client-key=analyst.key --embed-certs=true kubectl config set-context analyst-context --cluster=prod-cluster --user=analyst --namespace=data-analysis kubectl config use-context analyst-context

设置完成后验证：

kubectl get pods -n>apiVersion: v1 kind: ServiceAccount metadata: name: cleanup-job namespace: ops --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: ops name: cleanup-job-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "delete"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: ops name: cleanup-job-binding subjects: - kind: ServiceAccount name: cleanup-job namespace: ops roleRef: kind: Role name: cleanup-job-role apiGroup: rbac.authorization.k8s.io

Pod 里应用的访问凭证在/var/run/secrets/kubernetes.io/serviceaccount/token路径下，多数官方客户端库会自动读取该路径下的 Token 和 CA 证书。如果自研代码，也可以手动读取这个文件来构建客户端配置。

5. 常见问题与权限排查实录

5.1 为什么我的 Role 规则写了，却仍然 403

这类问题我见过很多次，大多数原因集中在几处。apiGroups 写错是最常见的一种。Pod 在空 API 组，Deployment 在 apps 组。把[""]与["apps"]混淆，权限自然不生效。

resources 写成复数或缩写等不规范形式，也会导致声明与请求不匹配。k8s 对大小写和复数形式是有要求的。

子资源没有在 resources 里列全。比如要读日志，却在 resources 里只写了pods，没有写pods/log，然后抱怨kubectl logs没权限。

verbs 缺少必要的操作。kubectl 某些操作需要的权限比直觉多。比如kubectl apply，本质上是 create 或 patch 的组合，如果角色里只给了 create，有些场景还是会失败。

排查时建议使用kubectl auth can-i快速验证：

kubectl auth can-i get pods --as dev-user -n>kubectl config view --minify --output jsonpath='{.users[0].name}' kubectl auth whoami

kubectl auth whoami会返回当前 kubeconfig 加载的真实身份。如果得到的名字和 RoleBinding 里 subjects.name 不一致，基本可以确定问题根源。

5.3 ServiceAccount 绑定到错误的命名空间

这是另一个高发问题。RoleBinding 里的 subjects 如果 kind 为 ServiceAccount，必须写明 namespace。不写的话，k8s 会当作 default 命名空间的对象，一旦找不到就会绑定失败。

比如你在 ci 命名空间创建了 ci-builder，RoleBinding 里如果写成：

subjects: - kind: ServiceAccount name: ci-builder

它会去 default 命名空间找 ci-builder，找不到对应的东西，权限自然不生效。正确写法是带上 namespace 字段。

5.4 Token 过期导致 Pod 内应用突然失联

有些集群开启了 Token 自动轮转，默认情况下的到期时间各有差异。如果 Pod 里的应用长期运行，且没有做自动重新读取 Token 的逻辑，到期后所有 API 调用会开始报 401。

排查方法也简单：进到 Pod 里看一下 Token 文件的时间戳，或者直接请求 API Server 试试。建议所有集群内客户端都实现 Token 的自动续期读取，而不是启动时读一次就缓存到进程结束。

5.5 集群角色被反复绑定，权限越滚越大

我见过不少团队为了省事，把 view、edit 甚至 cluster-admin 直接绑给所有人，最后权限体系形同虚设。这种操作短期内“方便”，长期看是定时炸弹。

一个相对可落地的治理建议是：尽量不用 ClusterRoleBinding 给普通用户绑集群级权限；每个团队尽量只操作自己所在的命名空间；确需跨命名空间只读的场景，优先使用 RoleBinding + ClusterRole 组合；异常密码、离职人员、过期证书要定期清理。

6. RBAC 权限治理的工程化实践

6.1 把权限配置代码化、版本化

生产环境不建议手动执行 kubectl apply 来维护权限。RBAC 属于基础设施的一部分，应该和 Deployment 一样放到 Git 仓库管理。每次修改都走合并请求和评审流程，这样可以完整记录权限变更历史。

一套简单的目录规划可以是：

rbac/ ├── namespaces/ │ └──>apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: RequestResponse verbs: ["create", "update", "patch", "delete"] resources: - group: "rbac.authorization.k8s.io" resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]

然后把审计日志投递到统一日志平台，定期检查权限变更记录。当有异常权限变化时，能够回溯到具体操作人，这在安全排查当中价值极大。

6.4 最小权限原则的落地技巧

最小权限原则说起来简单，做起来难。很多人给的权限都是“顺手给大一点”。我自己的建议是：先给只读权限，再根据实际需求逐步放开。如果某个用户声称需要 delete 权限，先问一句“删哪些、删了之后会不会影响别的业务”，宁可多走一步流程，也不要一开始就放开权限。

同时在写 Role 的时候，尽量把规则写细。比如只需要操作 Deployment，就不用给 StatefulSet、DaemonSet 的权限；只需要看日志，就只给 pods/log 的 get 权限，不一定要给 pods 的 get 权限（如果你能确认日志读取的工作机制，这点可以按需裁减）。规则越细，越接近真实业务需求，风险越小。

7. 从一次生产故障看权限配置边界

7.1 故障现场还原

某团队搭建了一个 CI/CD 流水线，给 CI 机器人绑定了一个比较宽的 ClusterRole。某次流水线脚本因为参数错误，误把命名空间里的 Deployment 全部删掉了。好在灰度环境有回滚机制，最终恢复，但也给团队提了一个醒：那个 CI 机器人根本不需要删除权限，它只需要 create、update 和 patch。

7.2 问题根因分析

权限过宽的直接原因是为了省事。配置人员当时想：“反正是内网 CI，应该不会乱来。”但自动化系统的特点是：一旦出错，它不会犹豫，也不会问。任何有权限的操作，都会在毫秒级执行完毕。所以给自动化系统授权的时候，权限边界必须比给人授权更严格。

7.3 可复用的改进方案

故障之后，团队做了三件事。一是把 CI 机器人的 ClusterRole 收紧为只写不删，把 delete 权限从角色里移除；二是增加了命名空间维度的 RoleBinding，让 CI 机器人只能在特定命名空间内操作；三是在准入控制层加了一个保护规则，禁止删除带有特定标签的命名空间资源，给关键业务上了一道保险。

这次故障的另外一个收获是：权限排查并不只是“加权限”就能解决的。更多时候，“去掉不合理的权限”才是更重要的动作。定期清理角色的 verb、resources、绑定关系，比临时加权限更能保证集群安全。

8. 最后一条实操建议

访问控制这一层，不太适合“边做边学”。等到出问题再补权限，往往已经是事故现场。建议新集群搭好之后，先把默认的 cluster-admin 之外的角色都用起来，给不同角色的人配不同权限，从一开始就养成最小授权的习惯。

两个立即能做的事情。第一，检查当前集群里有多少个 ClusterRoleBinding，打印出来逐个确认是否必要；第二，把所有 Pod 里使用 default ServiceAccount 的都梳理一遍，改成显式声明专用 ServiceAccount。这两步做完，集群的安全底子会有质的提升。