深入理解Kubernetes RBAC权限控制机制-优快云博客

本文链接：https://blog.youkuaiyun.com/gitblog_00095/article/details/148756582

深入理解Kubernetes RBAC权限控制机制

kubelabs Get Started with Kubernetes 项目地址: https://gitcode.com/gh_mirrors/ku/kubelabs

什么是RBAC

RBAC（基于角色的访问控制）是一种安全设计模式，它根据用户在系统中扮演的角色来限制对资源的访问权限。这种机制在现代IT系统中被广泛采用，特别是在Kubernetes这样的分布式系统中尤为重要。

想象一个没有RBAC的系统：所有用户只要通过用户名和密码认证，就能获得系统所有模块的完全访问权限。这种"全有或全无"的权限模型显然存在巨大安全隐患。即使系统区分普通用户和管理员，权限粒度仍然过于粗糙。

RBAC的必要性

在传统Linux系统中，用户要么是普通用户（权限受限），要么是root用户（拥有完全控制权）。这种二元权限模型存在明显缺陷：

root权限过大，容易因误操作导致系统故障
一旦root账户被入侵，整个系统将面临极高风险
无法根据实际工作需求精细划分权限

RBAC系统通过引入角色、访问级别和权限等概念，实现了更细粒度的权限控制。例如，备份管理员可以拥有备份工具的完全访问权限，但不应具备停止Web服务器或修改系统时间的权限。

Kubernetes中的RBAC实践

创建X509客户端证书用户

在Kubernetes中创建用户账户有多种认证方式，X509证书是其中一种常见方法。以下是创建步骤：

生成客户端密钥：

openssl genrsa -out div.key 2048

创建证书签名请求：

openssl req -new -key div.key -out div.csr -subj "/CN=div"

使用集群CA证书和密钥签署用户证书：

openssl x509 -req -in div.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out div.crt -days 300

将用户凭证添加到kubeconfig：

kubectl config set-credentials div --client-certificate=div.crt --client-key=div.key

角色(Role)与角色绑定(RoleBinding)

Kubernetes中的Role相当于其他RBAC实现中的"组"概念。我们不应该为每个用户单独定义授权规则，而是将这些规则附加到角色上，然后将用户与角色关联。

创建允许用户执行get pods命令的角色示例：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: get-pods
rules:
 - apiGroups: ["*"]
   resources: ["pods"]
   verbs: ["list"]

创建角色绑定将用户与角色关联：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: div-get-pods
subjects:
- kind: User
  name: div
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: get-pods
  apiGroup: rbac.authorization.k8s.io

权限控制详解

Kubernetes RBAC规则包含三个关键元素：

apiGroups：规则适用的API命名空间数组。例如Pod定义使用apiVersion: v1。"[*]"表示适用于任何API命名空间。
resources：规则适用的资源类型数组。可以指定对pods、jobs、deployments等资源的访问权限。
verbs：允许的操作动词数组。Kubernetes中的动词定义了可以对资源执行的操作类型：
- list：针对资源集合
- get：针对单个资源
- watch：监视资源变化
- create、update、delete等

更精细的权限控制示例

假设我们需要给用户div以下权限：

对Pod的只读访问（get和list）
不能直接删除Pod
通过Deployment间接管理Pod（如滚动更新）

相应角色定义如下：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: get-pods
rules:
 - apiGroups: ["*"]
   resources: ["pods"]
   verbs: ["list","get","watch"]
 - apiGroups: ["extensions","apps"]
   resources: ["deployments"]
   verbs: ["get","list","watch","create","update","patch","delete"]

集群范围授权：ClusterRole

ClusterRole与Role类似，但作用范围是整个集群而非特定命名空间。ClusterRole通常与ServiceAccount（集群内部使用和管理的账户）配合使用。

典型应用场景包括：

集群范围的服务发现组件（如External DNS）
为不同级别的集群管理员分配不同权限

创建ClusterRole和ClusterRoleBinding示例：

apiVersion: v1
kind: ServiceAccount
metadata:
 name: external-dns

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: external-dns
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["services"]
  verbs: ["get","watch","list"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["ingresses"]
  verbs: ["get","watch","list"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: external-dns-viewer
subjects:
- kind: ServiceAccount
  name: external-dns
  namespace: default
roleRef:
  kind: ClusterRole
  name: external-dns
  apiGroup: rbac.authorization.k8s.io