Kubernetes RBAC 访问控制实战手册如何用四步锁住用户与服务账户权限【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址: https://gitcode.com/gh_mirrors/ku/kubernetes-handbook本文基于 kubernetes-handbook 仓库的 RBAC 知识体系从一个常见的 Forbidden 报错讲起带你用 Role、ClusterRole、RoleBinding、ClusterRoleBinding 四类对象三步完成普通用户授权搞懂如何为服务账户分配最小权限、如何阅读集群内置系统角色、如何防止权限升级。文末附常见坑清单与上线前自查清单读完即可在自己的集群落地一套最小权限的授权方案。从 Forbidden 报错说起多用户集群为什么离不开 RBAC想象这个场景团队共用一份 admin kubeconfigCI 部署也用这个身份。某天脚本的 namespace 参数配错一条 delete 直接打到了生产命名空间——API Server 没有任何理由拦下它因为你就是超级用户。问题不在人出错而在集群缺少细粒度的访问控制。Kubernetes 1.6 之前不少集群用 ABAC基于属性的访问控制策略是 Master 节点上的一个文件改权限要 SSH 到节点改文件还必须重启 API Server 才生效。RBAC基于角色的访问控制改变了这套玩法权限直接映射成 API 资源授权动作可以用 kubectl 完成、立即生效甚至可以把授权管理权本身再委派给其他人。下表对比两种授权模式的核心差异维度ABACRBAC策略存放Master 节点配置文件API 资源kubectl 可查生效方式改文件并重启 API Serverkubectl/API 操作即时生效管理方式SSH 到节点改文件可把授权管理权限委派给用户从上表可以看出关键区别在于授权本身RBAC 把它变成了可管理、可审计的资源。仓库中的 Kubernetes 集群安全性配置最佳实践 建议用 RBAC 替代 AlwaysAllow 等粗放模式并设置--anonymous-authfalse禁用匿名访问。一句话RBAC 把授权从文件系统搬进 API可动态调整、可委派、可审计。三步完成首次授权从写角色到验证权限第 1 步用 Role 声明谁能做什么授权要回答的第一个问题是哪些资源、哪些操作下面的 Role 声明了default 命名空间中只读访问 pod这一权限apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: pod-reader rules: - apiGroups: [] # core API group resources: [pods] verbs: [get, watch, list]两个要点apiGroups: []表示 core APIrules 是纯累加的只能加权限不存在拒绝规则。仓库文档基于 1.6 撰写使用旧版rbac.authorization.k8s.io/v1beta1在新集群中把 apiVersion 换成rbac.authorization.k8s.io/v1即可字段写法不变。注意v1beta1 与 v1 的差异仅在 apiVersion 字段本文示例统一采用稳定的 v1 版本。第 2 步用 RoleBinding 把角色授给具体的人Role 只定义了权限集合它不知道发给谁。直接用 kubectl 内置命令创建绑定不必手写 YAML。以仓库实战中的 devuser 为例把它授为 dev 命名空间的 adminkubectl create rolebinding devuser-admin-binding \ --clusterroleadmin --userdevuser --namespacedev注意这里的--clusterroleadmin是集群范围的角色但用在 RoleBinding 里时只在绑定所在的命名空间生效——这正是角色定义权限集合、绑定决定作用范围的机制。要给 test 命名空间授权改一下--namespace再执行一次即可。第 3 步用 auth can-i 验证结果配置完不要猜要验证。auth can-i能以指定用户的视角模拟一次请求直接告诉你允不允许kubectl auth can-i get pods --asdevuser --namespacedev kubectl auth can-i list pods --asdevuser --namespacedefault预期输出分别是yes和no。如果你真的切到 devuser 的 kubeconfig 去执行kubectl get pods --namespacedefault这是你实际会看到的报错Error from server (Forbidden): User devuser cannot list pods in the namespace default. (get pods)这个 Forbidden 正是我们想要的边界。完整的证书生成 kubeconfig 组装流程仓库的 创建用户认证授权的 kubeconfig 文件 有逐步演示。一句话Role 声明权限Binding 授予到人can-i 秒级验证。幕后权限流转四类对象与内置默认角色RBAC 的授权决策发生在 API Server 内部每个 kubectl 请求先经过认证你是谁再进入 RBAC 授权器你能做什么。想长期写对授权得理解四类对象的作用域规则。范围怎么选Role 与 ClusterRole 不能混用Role只能授予单一命名空间内资源的权限ClusterRole额外支持集群范围资源如 nodes、非资源 endpoint如/healthz以及跨所有命名空间查询kubectl get pods --all-namespaces这类权限。常见用法是集群级定义通用 ClusterRole再用某个命名空间里的 RoleBinding 把它激活——这样用户只在该命名空间拿到权限。绑定主体有三种形态User、Group、ServiceAccount绑定的subjects字段接受三种主体User用户一个名字字符串、Group用户组、ServiceAccount服务账户。服务账户的命名有固定规则——用户名为system:serviceaccount:namespace:name同时属于system:serviceaccounts和system:serviceaccounts:namespace两个用户组这是后面按命名空间批量授权的根基。system:前缀为系统保留用户账号别用它起名。盘点内置角色认清哪些 system: 前缀不能碰启用 RBAC 后API Server 会自动创建一组默认的 ClusterRole 与 ClusterRoleBinding打上kubernetes.io/bootstrappingrbac-defaults标记并在每次启动时自动补齐缺失的权限与绑定——手工修改它们可能导致集群不可用。日常最常用的是四个面向用户的角色角色典型用法权限边界cluster-admin集群或命名空间超级用户对任何资源执行任何操作admin用 RoleBinding 绑定命名空间内读写不能改命名空间本身与配额edit用 RoleBinding 绑定命名空间内对象读写不能查看或修改绑定view用 RoleBinding 绑定命名空间内只读且看不到 secret注意view看不到 secret 是刻意设计——能读 secret 就等于能冒用其中携带的服务账户凭证。想直观查看集群里的授权关系可用可视化面板浏览 User、Role 与 Binding 之间的绑定图一句话Role 与 Binding 定范围Subject 定人system: 角色是集群地基。服务账户最小权限怎么给五档粒度默认 RBAC 策略很严格kube-system 之外的服务账户没有任何 API 权限发现类权限除外。也就是说每个应用的权限完全由你决定给多少。单应用授权专用 ServiceAccount 加只读角色在 pod spec 里指定serviceAccountName再为这个账户单独绑定角色kubectl create rolebinding my-sa-view \ --clusterroleview \ --serviceaccountmy-namespace:my-sa \ --namespacemy-namespace这样某个应用被攻破时攻击者也碰不到别的应用——爆炸半径被锁在该命名空间的只读。用 default 账号要当心全员继承pod 不指定serviceAccountName时会使用所在命名空间的 default 服务账户。给它授权等于命名空间内所有没指定账户的 pod 都继承这份权限。kube-system 里不少加载项就是这么跑的仓库的真实清单正是这种写法Heapster RBAC 配置 与 Dashboard RBAC 配置 都先建专用账户再绑定 cluster-adminkind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: heapster subjects: - kind: ServiceAccount name: heapster namespace: kube-system roleRef: kind: ClusterRole name: cluster-admin apiGroup: rbac.authorization.k8s.io警告把 cluster-admin 绑定给服务账户意味着对应 secret 里持有超级用户凭据——任何能读到这些 secret 的实体都应被视为超级用户。一条命令给命名空间内所有账户批量授权想让命名空间内所有账户共享同一权限用组写法即可kubectl create rolebinding serviceaccounts-view \ --clusterroleview \ --groupsystem:serviceaccounts:my-namespace \ --namespacemy-namespace五档粒度的权衡如下表从上到下安全性递减授权粒度代表写法安全性代价专用账户 专用角色--serviceaccountns:sa最高需逐个管理命名空间 default 角色--serviceaccountns:default中易扩散给命名空间全体命名空间级组--groupsystem:serviceaccounts:ns中按命名空间一刀切集群级受限角色--groupsystem:serviceaccounts低不鼓励集群级 cluster-admin同上改绑 cluster-admin极低强烈不推荐一句话给账户授权而不是给命名空间授权超级用户凭据绝不批发。⚠️ 常见坑Forbidden、resourceNames 与权限升级看到 Forbidden 先定位人再定位动词报错信息本身就是结构化的哪个用户、对哪个资源、哪个动词被拒。快速定位的办法是把当前身份的全部权限导出来对照kubectl auth can-i --list --assystem:serviceaccount:my-namespace:my-sa \ --namespacemy-namespace输出会按 API 组列出被允许的动作缺哪个动词一目了然。resourceNames 对 list 动词不生效resourceNames能把权限收窄到具体资源实例比如只允许 get 名为 my-configmap 的对象但 list、watch、create、deletecollection 这些动词与它搭配时不生效——因为这类请求的 URL 里根本不带资源名。如果你发现配置的角色好像没生效先检查是不是在带 resourceNames 的规则里配了 list。bind 动词如何防止权限被转手RBAC 在 API 层面防权限升级用户只能创建/修改自己已拥有其全部权限的角色要创建绑定要么拥有所引用角色的全部权限要么持有对该角色的显式bind动词。下面的规则就让 user-1 只能把 admin、edit、view 三个角色转手给别人碰不到 cluster-adminrules: - apiGroups: [rbac.authorization.k8s.io] resources: [clusterroles] verbs: [bind] resourceNames: [admin, edit, view]一句话API 层锁死了权限上限中间人无法送出自己没有的权限。生产环境ABAC 并行迁移与权限审计双授权器并行一个迭代平滑完成迁移长期跑 ABAC 的集群直接切纯 RBAC 会打断那些默认享受高权限的在集群内调 API 的应用。常见过渡方案是让两个授权器并行--authorization-modeRBAC,ABAC --authorization-policy-filemypolicy.jsonl任何一方放行请求即通过。此模式下把 API Server 日志级别开到 2 以上被 RBAC 拒绝的请求会留下RBAC DENY:前缀的日志——这就是待补齐谁需要什么权限的清单。给服务账户逐一授好角色、日志里不再有新的 DENY 之后再把 ABAC 摘掉。升级前做一次权限盘点归档关键身份的 can-i 输出日常运维建议对每个关键身份至少跑一次auth can-i --list并归档升级版本、引入新加载项前对照检查。每次授权都先回答两个问题这组 verbs 对这个人是否足够且不多余能否限定到单个命名空间任何一个答不上来就先别授。一句话用双授权器过渡期把隐式权限变成显式权限。速查清单授权前逐项核对序号检查项核对要点1Role 范围是否匹配需求能用 Role 就别用 ClusterRole2Subject 是否最小化用户/SA/组尽量避开组级批量授予3verbs 是否最小list 能否收敛成 get4default 服务账户是否被授权检查 pod 是否显式指定 serviceAccountName5system: 角色是否被动过确认无手工修改 rbac-defaults 对象6是否做过验证auth can-i 一次真实请求模拟延伸阅读RBAC 概念文档四类对象、默认角色与防升级的完整参考Kubernetes 中的 RBAC 支持实践ABAC 与 RBAC 的差异及迁移对在集群应用的影响创建用户认证授权的 kubeconfig 文件证书生成加 RoleBinding 的完整流程服务账户概念文档服务账户身份、用户组与 token 的对应关系Kubernetes 中的用户与身份认证授权授权主体的用户名与组从何而来【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址: https://gitcode.com/gh_mirrors/ku/kubernetes-handbook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考