走剧情的NPC

在前面的文章 权限、RBAC 和 ObjectPermission中，我详细介绍了 RBAC 的概念，k8s 中的 RBAC 和传统的 RBAC 又有一点点不同，我们一起来看看。

一、什么时候需要配置 RBAC

在你的应用需要访问 k8s 资源的时候，需要创建 ServiceAccount 并配置对应的权限。比如

• 公有云厂商读取 svc 结合自身 LoadBalancer 服务来完成负载均衡
• 开源项目的 operator 自定义了资源，需要配置自身账号能访问自定义的资源
• 自己开发的应用需要读取 k8s 资源

这里面常常包含几个对象：

• ServiceAccount
• ServiceAccount 需要访问的资源类型: Pod、Node、Secret、自定义资源 等等
• 对资源的操作权限，主要是 读、写、执行，完整列表如下
  • create
  • get
  • delete
  • list
  • update
  • edit
  • watch
  • exec

结合之前的 权限、RBAC 和 ObjectPermission，ServiceAccount 对应了之前所说的用户，后面的权限有点像 ObjectPermission，但面向的是一个大类，而不是一个具体的对象的权限。

二、全局资源和非全局资源

在 k8s 中，有些资源是全局的，不属于某个 namespace，比如 Node、StorageClass，有些资源是 namespace 级别的，所以在创建角色 Role的时候，要按资源类型分为 Role 和 ClusterRole

下面来举几个例子

2.1 、namespace 级别的权限配置

# 一个可以访问某个租户下的所有 pod 的权限

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-user1
  namespace: default

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: sa-role-all-pod-perm
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["*"]

# 关联用户和角色
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: rb-user1-all-pod-perm
  namespace: default
subjects:
- kind: ServiceAccount
  name: sa-user1
  namespace: default
roleRef:
  kind: Role
  name: sa-role-all-pod-perm
  apiGroup: rbac.authorization.k8s.io

2.2、cluster 级别的权限配置

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-user2
  namespace: default

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制
  name: secret-reader
rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 Secret 资源的名称为 "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: User
  name: sa-user2  
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

参考文章：

• Kubernetes 中的用户