k8s-----26、细粒度权限管理 RBAC

news2024/11/18 9:33:08

0、导读

每一个用户对API资源进行操作都需要通经过以下三个步骤：

第一步：对客户端访问进行认证操作，确认是否具有访问k8s权限(也就是通过serviceaccount)
token(共享秘钥)
SSL(双向SSL认证)
…通过任何一个认证即表示认证通过，进入下一步
第二步：授权检查，确认是否对资源具有相关的权限
ABAC(基于属性的访问控制)
RBAC(基于角色的访问控制)
NODE(基于节点的访问控制)
WEB HOOK(自定义HTTP回调方法的访问控制)
第三步：准入控制(对操作资源相关联的其他资源是否有权限操作)

1、基本概念

RBAC（Role-Based Access Control，基于角色的访问控制）是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问方法，其在Kubernetes 1.5版本中引入，在1.6时升级为Beta版本，并成为Kubeadm安装方式下的默认选项。启用RBAC需要在启动APIServer时指定–authorization-mode=RBAC。
RBAC使用rbac.authorization.k8s.io API组来推动授权决策，允许管理员通过Kubernetes API动态配置策略。
RBAC API声明了4种顶级资源对象，即Role、ClusterRole、RoleBinding、ClusterRoleBinding，管理员可以像使用其他API资源一样使用kubectl API调用这些资源对象。例如：kubectl create -f (resource).yml。
RBAC常用官网示例
curl https://127.0.0.1:6443/healthz -k 补充小知识，对apiserver检测健康度

2、资源对象

在这里插入图片描述

2.1 Role和ClusterRole

Role和ClusterRole的关键区别是，Role是作用于命名空间内的角色，ClusterRole作用于整个集群的角色。

2.1.1 Role

在RBAC API中，Role包含表示一组权限的规则。权限纯粹是附加允许的，没有拒绝规则。
Role只能授权对单个命名空间内的资源的访问权限，比如授权对default命名空间的读取权限：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default 
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates(定义) the core API group
  resources: ["pods"]  #资源类型
  verbs: ["get", "watch", "list"] #权限

2.1.2 ClusterRole

ClusterRole也可将上述权限授予作用于整个集群的Role，主要区别是，ClusterRole是集群范围的，因此它们还可以授予对以下内容的访问权限：

集群范围的资源（如Node）。
非资源端点（如/healthz）。
跨所有命名空间的命名空间资源（如Pod）。
比如，授予对任何特定命名空间或所有命名空间中的secret的读权限（取决于它的绑定方式）：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

2.1.3 参数解释

➢ kind:定义资源类型为Role
➢ API Version:定义该资源的API版本，建议使用v1版本，因为其它版本如beta版本在Kubernetes1.22+ 将被彻底启用
➢ metadata:元数据定义
	◼ namespace:因为Role是作用单个Namespace下的，具有命名空间隔离，所以需要制定
Namespace，不指定则为default ◼ name:Role的名称
➢ rules:定义具体的权限，切片类型，可以配置多个
	◼ APIGroups:包含该资源的apiGroup名称，比如extension
	◼ resources:定义对哪些资源进行授权，切片类型，可以定义多个，比如pods、service等
	◼ verbs:定义可以执行的操作，切片类型，可以定义多个，比如create、delete、list、get、watch、deletecollection等

2.2 RoleBinding和ClusterRoleBinding

RoleBinding将Role中定义的权限授予User、Group或Service Account。RoleBinding和ClusterRoleBinding最大的区别与Role和ClusterRole的区别类似，即RoleBinding作用于命名空间，ClusterRoleBinding作用于集群。

2.2.1 RoleBinding

RoleBinding可以引用同一命名空间的Role进行授权，比如将上述创建的pod-reader的Role授予default命名空间的用户jane，这将允许jane读取default命名空间中的Pod：

# This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default  #需要设置命名空间
subjects: #你可以指定不止一个授权的subjects(主体)
- kind: User
  name: jane # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io #可以省略

说明：

roleRef：绑定的类别，可以是Role或ClusterRole。
RoleBinding也可以引用ClusterRole来授予对命名空间资源的某些权限。管理员可以为整个集群定义一组公用的ClusterRole，然后在多个命名空间中重复使用。
比如，创建一个RoleBinding引用ClusterRole，授予dave用户读取development命名空间的Secret：

# This role binding allows "dave" to read secrets in the "development" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets
  namespace: development # This only grants permissions within the "development" namespace.
subjects: