k8s RBAC简介

Posted 2021-04-23 苍雪明南

    上一篇对RBAC做了一个简单的介绍，接下来我们一起看看更为具体的细节。

    
Role 和 ClusterRole

    RBAC 的 Role 或 ClusterRole 中包含一组代表相关权限的规则。 需要注意的是，这些权限是纯粹累加的（不存在拒绝某操作的规则）。Role的作用范围是某个命名空间（namespace），而ClusterRole的作用范围则是整个k8s集群。为什么在Role之后，还会出现ClusterRole呢？其一是因为有些对象，不是namespace级别的，比如node，其二是我们是需要一些权限，能够对整个集群所有namespace都产生作用，这个时候用Role的话就会相对麻烦。

    摘自官网的Role示例：

apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: namespace: default name: pod-readerrules:- apiGroups: [""] # "" 标明 core API 组 resources: ["pods"] verbs: ["get", "watch", "list"]

    第一行是说明Role的api具体是什么（rbac.authorization.k8s.io），是哪个版本（v1）；

    第二行表明这个api类型是Role；

    第三行是关于这个api的元数据信息：属于default namespace，名字叫做pod-reader。

    第四行是描述该Role的具体权限：apiGroups: [""]：表明作用于的api组是core groups；resources: ["pods"]：可操作的资源对象列表是：pod（注意在编写yaml文件时，资源对象都需要是复数）；verbs: ["get", "watch", "list"]：表示具体的权限：此处的权限是三个：get、watch、list。

    摘自官网的ClusterRole示例：

apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:  # "namespace" 被忽略，因为 ClusterRoles 不受命名空间限制 name: secret-readerrules:- apiGroups: [""] # 在 HTTP 层面，用来访问 Secret 对象的资源的名称为 "secrets" resources: ["secrets"] verbs: ["get", "watch", "list"]

    与Role相比，主要有两处不同，一是kind从Role变为ClusterRole，二是metadata部分的namespace直接被忽略，原因也说明了，就是ClusterRole不受namespace限制。

RoleBinding 和 ClusterRoleBinding

    类似Role和ClusterRole，RoleBinding也有一个对应集群对象，即ClusterRoleBinding。两者的区别也和Role与ClusterRole一致，一个作用于Role，一个作用于ClusterRole。RoleBinding是将角色中定义的权限赋予一个或者一组用户。它包含若干主体（用户、组或服务账户，常见的是sa，Service account）的列表和对这些主体所获得的角色的引用。RoleBinding 在指定的namespace中执行授权，而 ClusterRoleBinding 在集群范围执行授权。

    摘自官网的RoleBinding示例：

    下面的例子中的 RoleBinding 将 "pod-reader" Role 授予在 "default" namespace中的用户 "jane"。这样，用户 "jane" 就具有了读取 "default" namespace中 pods 的权限。

apiVersion: rbac.authorization.k8s.io/v1# 此角色绑定允许 "jane" 读取 "default" 命名空间中的 Podskind: RoleBindingmetadata: name: read-pods namespace: defaultsubjects:# 你可以指定不止一个“subject（主体）”- kind: User name: jane # "name" 是不区分大小写的 apiGroup: rbac.authorization.k8s.ioroleRef: # "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系 kind: Role # 此字段必须是 Role 或 ClusterRole name: pod-reader # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配 apiGroup: rbac.authorization.k8s.io

    值得注意的是，RoleBinding和Role，ClusterRoleBinding和ClusterRole也不是一一绑定的。RoleBinding 也可以引用 ClusterRole（反过来ClusterRoleBinding引用Role则意义不大），以将对应 ClusterRole 中定义的访问权限授予 RoleBinding 所在namespace的资源。这种引用使得你可以跨整个集群定义一组通用的角色， 之后在多个namespace中复用。

    摘自官网的示例：尽管下面的 RoleBinding 引用的是一个 ClusterRole，"dave"（这里的主体， 不区分大小写）只能访问 "development" namespace中的 Secrets 对象，因为 RoleBinding 所在的namespace（由其 metadata 决定）是 "development"。

apiVersion: rbac.authorization.k8s.io/v1# 此角色绑定使得用户 "dave" 能够读取 "default" 命名空间中的 Secrets# 你需要一个名为 "secret-reader" 的 ClusterRolekind: RoleBindingmetadata: name: read-secrets  # RoleBinding 的命名空间决定了访问权限的授予范围。  # 这里仅授权在 "development" 命名空间内的访问权限。 namespace: developmentsubjects:- kind: User name: dave # 'name' 是不区分大小写的 apiGroup: rbac.authorization.k8s.ioroleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding 示例

    摘自官网：下面的 ClusterRoleBinding 允许 "manager" 组内的所有用户访问任何namespace中的 Secrets。

apiVersion: rbac.authorization.k8s.io/v1# 此集群角色绑定允许 “manager” 组中的任何人访问任何命名空间中的 secretskind: ClusterRoleBindingmetadata: name: read-secrets-globalsubjects:- kind: Group name: manager # 'name' 是不区分大小写的 apiGroup: rbac.authorization.k8s.ioroleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io

    

    创建了绑定（RoleBinding和ClusterRoleBinding）之后，你不能再修改绑定对象所引用的 Role 或 ClusterRole。试图改变绑定对象的 roleRef 将导致合法性检查错误。如果你想要改变现有绑定对象中 roleRef 字段的内容，必须删除重新创建绑定对象。

    这种限制有两个主要原因：

    针对不同角色的绑定是完全不一样的绑定。要求通过删除/重建绑定来更改 roleRef, 这样可以确保要赋予绑定的所有主体会被授予新的角色（而不是在允许修改 roleRef 的情况下导致所有现有主体未经验证即被授予新角色对应的权限）。

    将 roleRef 设置为不可以改变，这使得可以为用户授予对现有绑定对象的 update 权限， 这样可以让他们管理主体列表，同时不能更改被授予这些主体的角色。

subjects的类型

对于名称为 [e-mail] 的用户：

subjects:- kind: User name: "[e-mail]" apiGroup: rbac.authorization.k8s.io

对于名称为 frontend-admins 的用户组：

subjects:- kind: Group name: "frontend-admins" apiGroup: rbac.authorization.k8s.io

对于 kube-system 名字空间中的默认服务账户：

subjects:- kind: ServiceAccount name: default namespace: kube-system

对于任何名称空间中的 "qa" 组中所有的服务账户：

subjects:- kind: Group name: system:serviceaccounts:qa apiGroup: rbac.authorization.k8s.io

对于 "development" 名称空间中 "dev" 组中的所有服务帐户：

subjects:- kind: Group name: system:serviceaccounts:dev apiGroup: rbac.authorization.k8s.io namespace: development

对于在任何名字空间中的服务账户：

subjects:- kind: Group name: system:serviceaccounts apiGroup: rbac.authorization.k8s.io

对于所有已经过认证的用户：

subjects:- kind: Group name: system:authenticated apiGroup: rbac.authorization.k8s.io

对于所有未通过认证的用户：

subjects:- kind: Group name: system:unauthenticated apiGroup: rbac.authorization.k8s.io

对于所有用户：

subjects:- kind: Group name: system:authenticated apiGroup: rbac.authorization.k8s.io- kind: Group name: system:unauthenticated  apiGroup: rbac.authorization.k8s.io

RBAC相关的命令

kubectl create role：创建 Role 对象，定义在某一namespace中的权限

kubectl create clusterrole：创建 ClusterRole 对象

kubectl create rolebinding：在特定的名字空间中对 Role 或 ClusterRole 授权

kubectl create clusterrolebinding：在整个集群（所有名字空间）中用 ClusterRole 授权

kubectl auth reconcile：使用清单文件来创建或者更新 rbac.authorization.k8s.io/v1 API 对象。