13.RBAC | Evergreen Notes

1.RBAC

1.1.RBAC是什么

基于角色（Role）的访问控制（RBAC）是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法。其在Kubernetes 1.5版本中引入，在1.6版本中升级为Beta版本，并成为Kubeadm安装方式下的默认选项。

RBAC 鉴权机制使用 rbac.authorization.k8s.io API 组来驱动鉴权决定，允许你通过 Kubernetes API 动态配置策略。

要启用 RBAC，在启动 API 服务器时将 --authorization-mode 参数设置为一个逗号分隔的列表并确保其中包含 RBAC。

BASH

kube-apiserver --authorization-mode=Example,RBAC --<其他选项> --<其他选项>

1.2.RBAC出现背景

在生产环境中，Kubernetes管理员具有Kubernetes集群中各类资源增删改查的权限，并且也具有授权其他用户权限的权限。之前提到过使用kubectl客户端工具操作集群时，会默认使用～/.kube/config文件访问集群，该文件具有操作集群的各类权限，有可能是管理员权限，也有可能只是某个命名空间的权限。在实际使用时，需要访问并操作Kubernetes集群的不仅仅是管理员，也有可能是某个项目的负责人、某个应用的开发者等，所以在Kubernetes中实现细粒度的权限管理是一件很重要的事情，而具体权限的管控都由一个叫RBAC的资源进行管理配置。

1.3.RBAC对象分类

RBAC API 声明了四种 Kubernetes 对象：Role、ClusterRole、RoleBinding 和 ClusterRoleBinding。你可以像使用其他 Kubernetes 对象一样，通过类似 kubectl 这类工具描述或修补RBAC 对象。

1.3.1.Role 和 ClusterRole

RBAC 的 Role 或 ClusterRole 中包含一组代表相关权限的规则。这些权限是纯粹累加的（不存在拒绝某操作的规则）。

Role 总是用来在某个名字空间内设置访问权限；在你创建 Role 时，你必须指定该 Role 所属的名字空间。

与之相对，ClusterRole 则是一个集群作用域的资源。这两种资源的名字不同（Role 和 ClusterRole）是因为 Kubernetes 对象要么是名字空间作用域的，要么是集群作用域的，不可两者兼具。

ClusterRole 有若干用法。你可以用它来：

定义对某名字空间域对象的访问权限，并将在个别名字空间内被授予访问权限；
为名字空间作用域的对象设置访问权限，并被授予跨所有名字空间的访问权限；
为集群作用域的资源定义访问权限。

小结:Role和ClusterRole的关键区别是，Role是作用于命名空间内的角色，ClusterRole是作用于整个集群的集群角色。在RBAC API中，Role包含表示一组权限的规则。权限纯粹是附加允许的，没有拒绝规则。

1.3.2.RoleBinding 和 ClusterRoleBinding

角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户。它包含若干主体（Subject）（用户、组或服务账户）的列表和对这些主体所获得的角色的引用。 RoleBinding 在指定的名字空间中执行授权，而 ClusterRoleBinding 在集群范围执行授权。

一个 RoleBinding 可以引用同一的名字空间中的任何 Role。或者，一个 RoleBinding 可以引用某 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 所在的名字空间。如果你希望将某 ClusterRole 绑定到集群中所有名字空间，你要使用 ClusterRoleBinding。

RoleBinding 或 ClusterRoleBinding 对象的名称必须是合法的路径分段名称。

小结:RoleBinding和ClusterRoleBinding最大的区别与Role和ClusterRole的区别类似，即RoleBinding作用于命名空间，ClusterRoleBinding作用于集群。

1.4.对集群资源的权限控制

在 Kubernetes API 中，大多数资源都是使用对象名称的字符串表示来呈现与访问的。例如，对于 Pod 应使用 "pods"。 RBAC 使用对应 API 端点的 URL 中呈现的名字来引用资源。有一些 Kubernetes API 涉及子资源（subresource），例如 Pod 的日志。对 Pod 日志的请求看起来像这样：

BASH

GET /api/v1/namespaces/{namespace}/pods/{name}/log

在这里，pods 对应名字空间作用域的 Pod 资源，而 log 是 pods 的子资源。在 RBAC 角色表达子资源时，使用斜线（/）来分隔资源和子资源。要允许某主体读取 pods 同时访问这些 Pod 的子资源，你可以这样写：

YAML

对于某些请求，也可以通过 resourceNames 列表按名称引用资源。在指定时，可以将请求限定为资源的单个实例。下面的例子中限制可以 get 和 update 一个名为 my-configmap 的ConfigMap：

YAML

注意:如果使用了resourceNames，则verbs不能是list、watch、create、deletecollection等。

1.5.RBAC对象配置解析

1.5.1.Role

在RBAC API中，Role包含表示一组权限的规则。权限纯粹是附加允许的，没有拒绝规则。

Role只能授权对单个命名空间内的资源的访问权限，比如授权对default命名空间的读取权限：

YAML

上面参数说明如下：

kind：定义资源类型为Role
apiVersion：定义该资源的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等

1.5.2.ClusterRole

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

集群范围的资源（如Node）
非资源端点（如/healthz）
跨所有命名空间的命名空间资源（如Pod）

比如，授予对任何特定命名空间或所有命名空间中的secret的读权限（取决于它的绑定方式）

YAML

1.5.3.RoleBinding

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

YAML

上面参数说明如下:

roleRef：绑定的类别，可以是Role或ClusterRole

RoleBinding也可以引用ClusterRole来授予对命名空间资源的某些权限。管理员可以为整个集群定义一组公用的ClusterRole，然后在多个命名空间中重复使用。

比如，创建一个RoleBinding引用ClusterRole，授予dave用户读取development命名空间的Secret：

YAML

上面参数说明如下:

roleRef：绑定的类别，可以是Role或ClusterRole

1.5.4.ClusterRoleBinding

ClusterRoleBinding可用于在集群级别和所有命名空间中授予权限，比如允许组manager中的所有用户都能读取任何命名空间的Secret：

YAML

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

1.6.RBAC配置示例

1.6.1.Role示例

1.允许读取在核心 API 组]下的 "pods"：

YAML

2.允许在 "apps" API 组中读/写 Deployment（在 HTTP 层面，对应 URL 中资源部分为 "deployments"）：

YAML

3.允许读取核心 API 组中的 Pod 和读/写 "batch" API 组中的 Job 资源：

YAML

4.允许读取名称为 "my-config" 的 ConfigMap（需要通过 RoleBinding 绑定以限制为某名字空间中特定的 ConfigMap）

YAML

5.允许读取在核心组中的 "nodes" 资源（因为 Node 是集群作用域的，所以需要 ClusterRole 绑定到 ClusterRoleBinding 才生效）：

YAML

6.允许针对非资源端点 /healthz 和其子路径上发起 GET 和 POST 请求（必须在 ClusterRole 绑定 ClusterRoleBinding 才生效）：

YAML

1.6.2.RoleBinding示例

RoleBinding 或者 ClusterRoleBinding 可绑定角色到某**主体（Subject）**上。主体可以是组，用户或者服务账户。

Kubernetes 用字符串来表示用户名。用户名可以是普通的用户名，像 "alice"；或者是邮件风格的名称，如 "bob@example.com"，或者是以字符串形式表达的数字 ID。你作为 Kubernetes 管理员负责配置身份认证模块，以便后者能够生成你所期望的格式的用户名。

注意：前缀 system: 是 Kubernetes 系统保留的，所以你要确保所配置的用户名或者组名不能出现上述 system: 前缀。除了对前缀的限制之外，RBAC 鉴权系统不对用户名格式作任何要求

1.对于名称为 alice@example.com 的用户：

YAML

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

YAML

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

YAML

4.对于 "qa" 名称空间中的所有服务账户：

YAML

上面参数说明:

服务账户的用户名前缀为 system:serviceaccount:，属于前缀为 system:serviceaccounts: 的用户组。
system:serviceaccount: （单数）是用于服务账户用户名的前缀

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

YAML

上面参数说明:

服务账户的用户名前缀为 system:serviceaccount:，属于前缀为 system:serviceaccounts: 的用户组。
system:serviceaccounts: （复数）是用于服务账户组名的前缀

6.对于所有已经过身份认证的用户：

YAML

7.对于所有未通过身份认证的用户：

YAML

8.对于所有用户：

YAML

1.7.RBAC角色分类

API 服务器创建一组默认的 ClusterRole 和 ClusterRoleBinding 对象。这其中许多是以 system: 为前缀的，用以标识对应资源是直接由集群控制面管理的。所有的默认 ClusterRole 和 ClusterRoleBinding 都有 kubernetes.io/bootstrapping=rbac-defaults 标签。

注意：在修改名称包含 system: 前缀的 ClusterRole 和 ClusterRoleBinding 时要格外小心。对这些资源的更改可能导致集群无法正常运作。

无论是经过身份验证的还是未经过身份验证的用户，默认的角色绑定都授权他们读取被认为是可安全地公开访问的 API（包括 CustomResourceDefinitions）。如果要禁用匿名的未经过身份验证的用户访问，请在 API 服务器配置中中添加 --anonymous-auth=false 的配置选项。

通过运行命令 kubectl 可以查看这些角色的配置信息:

BASH

# kubectl get clusterroles system:discovery -o yaml

说明：如果你编辑该 ClusterRole，你所作的变更会被 API 服务器在重启时自动覆盖，这是通过自动协商机制完成的。要避免这类覆盖操作，要么不要手动编辑这些角色，要么禁止自动协商机制。

1.7.1.面向用户的角色

一些默认的 ClusterRole 不是以前缀 system: 开头的。这些是面向用户的角色。它们包括超级用户（Super-User）角色（cluster-admin）、使用 ClusterRoleBinding 在集群范围内完成授权的角色（cluster-status）、以及使用 RoleBinding 在特定名字空间中授予的角色（admin、edit、）。

面向用户的 ClusterRole 使用 ClusterRole 聚合以允许管理员在这些 ClusterRole 上添加用于定制资源的规则。如果想要添加规则到 admin、edit 或者 view，可以创建带有以下一个或多个标签的 ClusterRole：

YAML

1.7.2.核心组件角色

1.7.3.其他组件角色

1.7.4.内置控制器的角色

Kubernetes 控制器管理器运行内建于 Kubernetes 控制面的控制器。当使用 --use-service-account-credentials 参数启动时，kube-controller-manager 使用单独的服务账户来启动每个控制器。每个内置控制器都有相应的、前缀为 system:controller: 的角色。如果控制管理器启动时未设置 --use-service-account-credentials，它使用自己的身份凭据来运行所有的控制器，该身份必须被授予所有相关的角色。这些角色包括：

BASH

1.8.使用命令行工具创建RBAC对象

1.8.1.创建Role

1.创建名称为 “pod-reader” 的 Role 对象，允许用户对 Pods 执行 get、watch 和 list 操作

BASH

$ kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods

2.创建名称为 “pod-reader” 的 Role 对象并指定 resourceNames

BASH

$ kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

3.创建名为 “foo” 的 Role 对象并指定 apiGroups

BASH

$ kubectl create role foo --verb=get,list,watch --resource=replicasets.apps

4.创建名为 “foo” 的 Role 对象并指定子资源权限

BASH

$ kubectl create role foo --verb=get,list,watch --resource=pods,pods/status

5.创建名为 “my-component-lease-holder” 的 Role 对象，使其具有对特定名称的资源执行 get/update 的权限

BASH

$ kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component

1.8.2.创建ClusterRole

1.创建名称为 “pod-reader” 的 ClusterRole 对象，允许用户对 Pods 对象执行 get、 watch 和 list 操作

BASH

$ kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods

2.创建名为 “pod-reader” 的 ClusterRole 对象并指定 resourceNames

BASH

$ kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

3.创建名为 “foo” 的 ClusterRole 对象并指定 apiGroups

BASH

$ kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps

4.创建名为 “foo” 的 ClusterRole 对象并指定子资源

BASH

$ kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status

5.创建名为 “foo” 的 ClusterRole 对象并指定 nonResourceURL

BASH

$ kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*

6.创建名为 “monitoring” 的 ClusterRole 对象并指定 aggregationRule：

BASH

$ kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"

1.8.3.创建rolebinding

1.在名字空间 “acme” 中，将名为 admin 的 ClusterRole 中的权限授予名称 “bob” 的用户

BASH

$ kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme

2.在名字空间 “acme” 中，将名为 view 的 ClusterRole 中的权限授予名字空间 “acme” 中名为 myapp 的服务账户

BASH

$ kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme

3.在名字空间 “acme” 中，将名为 view 的 ClusterRole 对象中的权限授予名字空间 “myappnamespace” 中名称为 myapp 的服务账户

BASH

$ kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme

1.8.4.创建clusterrolebinding

1.在整个集群范围，将名为 cluster-admin 的 ClusterRole 中定义的权限授予名为 “root” 用户：

BASH

$ kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root

2.在整个集群范围内，将名为 system:node-proxier 的 ClusterRole 的权限授予名为 “system:kube-proxy” 的用户

BASH

$ kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy

3.在整个集群范围内，将名为 view 的 ClusterRole 中定义的权限授予 “acme” 名字空间中名为 “myapp” 的服务账户

BASH

$ kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme

1.8.5.创建或者更新 API 对象

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

尚不存在的对象会被创建，如果对应的名字空间也不存在，必要的话也会被创建。已经存在的角色会被更新，使之包含输入对象中所给的权限。如果指定了 --remove-extra-permissions，可以删除额外的权限。

已经存在的绑定也会被更新，使之包含输入对象中所给的主体。如果指定了 --remove-extra-permissions，则可以删除多余的主体。

1.测试应用 RBAC 对象的清单文件，显示将要进行的更改

BASH

$ kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client

2.应用 RBAC 对象的清单文件，保留角色（roles）中的额外权限和绑定（bindings）中的其他主体

BASH

$ kubectl auth reconcile -f my-rbac-rules.yaml

3.应用 RBAC 对象的清单文件，删除角色（roles）中的额外权限和绑定中的其他主体

BASH

$ kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions

1.9.聚合ClusterRole

你可以将若干 ClusterRole 聚合（Aggregate） 起来，形成一个复合的 ClusterRole。作为集群控制面的一部分，控制器会监视带有 aggregationRule 的 ClusterRole 对象集合。aggregationRule 为控制器定义一个标签选择算符供后者匹配应该组合到当前 ClusterRole 的 roles 字段中的 ClusterRole 对象。

注意：控制平面会覆盖你在聚合 ClusterRole 的 rules 字段中手动指定的所有值。如果你想更改或添加规则，请在被 aggregationRule 所选中的 ClusterRole 对象上执行变更。

比如，匹配http://rbac.example.com/aggregate-to-monitoring: "true"标签来创建聚合ClusterRole：

YAML

然后创建与标签选择器匹配的ClusterRole向聚合ClusterRole添加规则：

YAML

下面进行示例演示:

1.定义一个yaml文件，权限为空

YAML

2.创建ClusterRole

BASH

root@k8s-master01:~/hhh# kubectl create -f  a-clusterrole.yaml 
clusterrole.rbac.authorization.k8s.io/test-aggregation created

3.查看ClusterRole权限为空

YAML

4.创建一个sa

BASH

root@k8s-master01:~/hhh# kubectl create sa test-aggregation 
serviceaccount/test-aggregation created

5.给sa创建secret，v1.25版本后创建sa后不再自动创建secret，因此需要手动创建。secret中会包含一些认证信息，包括ca证书等。

YAML

6.查看token,用于登录dashboard

BASH

说明:上面的token需要根据自己的环境进行查看

7.新建一个clusterrolebinding绑定clusterrole

BASH

[root@k8s-master01 study]# kubectl create clusterrolebinding test-aggregation --clusterrole=test-aggregation --serviceaccount=defalut:test-aggregation

8.在Master01节点上查看端口号,观察到端口号为30757

BASH

9.根据自己的实例端口号，通过任意安装了kube-proxy的宿主机的IP+端口即可访问到dashboard。[https://192.168.20.235:31449](https选择登录方式为令牌（即token方式）。发现权限不够

10.新建一个ClusterRole，通过http://rbac.example.com/aggregate-to-monitoring: "true"标签创建聚合ClusterRole

YAML

11.创建一个权限

BASH

root@k8s-master01:~# kubectl create -f b-clusterrole.yaml
clusterrole.rbac.authorization.k8s.io/b-aggregation created

12.查看权限是否更新，观察到权限已经更改

YAML

12.在浏览器上刷新进行查看，观察到指定权限可以操作

1.10.RBAC企业实践

针对用户管理，一个公司内部可能有很多项目，每个项目可能对应一个Namespace，其次一个公司有很多项目组，每个项目组对应很多项目，最后一个公司有很多研发人员，每个研发人员可能对应很多项目。所以我们的用户名可以使用项目名称或者项目对应的Namespace进行设置，比如有一个bank-a项目，可以先创建一个名为bank-a的ServiceAccount，然后针对这个ServiceAccount进行授权，那么研发人员或者其他Kubernetes运维人员就有了相关的权限。当然，对于ServiceAccount基于什么创建，可以根据实际情况来管理，用项目名称也是可以的。

针对权限管理，在实际使用时，无论是Kubernetes的Dashboard还是其他方式操作Kubernetes集群的资源，其所做的主要工作无非就是增删改查，而针对非Kubernetes管理人员进行授权，权限一般不会太高，并且大部分情况下可授予相同的权限。比如想要查看某个Namespace下Pod的日志或在Pod中执行命令等，此类权限是统一的，只不过是授权到了不同的ServiceAccount，所以可以使用ClusterRole定义一些权限“模板”，然后使用Rolebinding绑定到指定ServiceAccount即可。

在企业中我们需要管理权限和用户---给不同的用户赋予不同的权限，那么如何管理权限和用户呢？总体思路一般如下：

创建好通用权限-ClusterRole
Namespace列表查看权限
日志查看权限
执行命令权限
Pod删除权限
资源编辑权限
其他权限
把通用权限分配到人

下面我们通过设定一定的需求给不同的用户赋予不同的权限,具体的需求如下:

用户user1可以查看default、kube-system下Pod的日志
用户user2可以在default下的Pod中执行命令，并且可以删除Pod

1.创建通用权限 (1)创建通用权限-list

YAML

(2)创建通用权限-delete

YAML

(3)创建通用权限-exec

YAML

(4)创建通用权限-log

YAML

2.创建用户管理命名空间

BASH

[root@k8s-master01 study]# kubectl create ns kube-users

3.创建用户

BASH

[root@k8s-master01 study]# kubectl create sa user1 
[root@k8s-master01 study]# kubectl create sa user2

4.创建secert

5.获取两个用户的token (1)获取user1用户的token

BASH

(2)获取user2用户的token

BASH

6.绑定全局命名空间查看权限

YAML

7.在Master01节点上查看端口号,观察到端口号为31449

BASH

8.使用浏览器输入[https://192.168.20.235:31449/]登录dashboard，token如上。观察到已经可以切换命名空间,其他没权限

9.赋予用户user1可以查看default、kube-system下Pod的日志权限

BASH

10.使用浏览器输入[https://192.168.20.235:31449/]登录dashboard，输入用户user1的token。操作后观察到用户user1只可以查看default、kube-system下Pod的日志，其他做不了

11.赋予用户default可以在kube-system下的Pod中执行命令，并且可以删除Pod权限

BASH

12.使用浏览器输入[https://192.168.20.235:31449/]登录dashboard，输入用户user2的token。操作后观察到用户user2在default下的Pod中执行命令，并且可以删除Pod权限

在default下测试pod是否可以执行，观察到Pod可以被成功执行

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 ConfigMap 资源的名称为 "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

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"]

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"]

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
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

# 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:
- kind: User
  name: dave # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 Pod 资源的名称为 "pods"
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

rules:
- apiGroups: ["apps"]
  #
  # 在 HTTP 层面，用来访问 Deployment 资源的名称为 "deployments"
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 Pod 资源的名称为 "pods"
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  # 在 HTTP 层面，用来访问 Job 资源的名称为 "jobs"
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 ConfigMap 资源的名称为 "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-config"]
  verbs: ["get"]

rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 Node 资源的名称为 "nodes"
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"] # nonResourceURL 中的 '*' 是一个全局通配符
  verbs: ["get", "post"]

subjects:
- kind: User
  name: "alice@example.com"
  apiGroup: rbac.authorization.k8s.io

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

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

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

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

metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"

默认 ClusterRole	                 默认 ClusterRoleBinding	                                      描述
cluster-admin	                  system:masters 组	                 允许超级用户在平台上的任何资源上执行所有操作。 当在 ClusterRoleBinding 中使用时，可以授权对集群中以及所有名字空间中的全部资源进行完全控制。 当在 RoleBinding 中使用时，可以授权控制角色绑定所在名字空间中的所有资源，包括名字空间本身。
admin	                          无	                                 允许管理员访问权限，旨在使用 RoleBinding 在名字空间内执行授权。如果在 RoleBinding 中使用，则可授予对名字空间中的大多数资源的读/写权限， 包括创建角色和角色绑定的能力。 此角色不允许对资源配额或者名字空间本身进行写操作。 此角色也不允许对 Kubernetes v1.22+ 创建的 EndpointSlices（或 Endpoints）进行写操作。
edit	                          无	                                 允许对名字空间的大多数对象进行读/写操作。此角色不允许查看或者修改角色或者角色绑定。 不过，此角色可以访问 Secret，以名字空间中任何 ServiceAccount 的身份运行 Pod， 所以可以用来了解名字空间内所有服务账户的 API 访问级别。 此角色也不允许对 Kubernetes v1.22+ 创建的 EndpointSlices（或 Endpoints）进行写操作。
view	                          无	                                 允许对名字空间的大多数对象有只读权限。 它不允许查看角色或角色绑定。此角色不允许查看 Secret，因为读取 Secret 的内容意味着可以访问名字空间中 ServiceAccount 的凭据信息，进而允许利用名字空间中任何 ServiceAccount 的身份访问 API（这是一种特权提升）。

默认 ClusterRole	                  默认 ClusterRoleBinding	                                           描述
system:kube-scheduler	           system:kube-scheduler 用户	                   允许访问 scheduler组件所需要的资源。
system:volume-scheduler	s          ystem:kube-scheduler 用户	                   允许访问 kube-scheduler 组件所需要的卷资源。
system:kube-controller-manager	   system:kube-controller-manager 用户	       允许访问控制器管理器组件所需要的资源。 各个控制回路所需要的权限在控制器角色详述。
system:node	                       无	                                        允许访问 kubelet 所需要的资源，包括对所有 Secret 的读操作和对所有 Pod 状态对象的写操作。你应该使用 Node 鉴权组件和 NodeRestriction 准入插件而不是 system:node 角色。同时基于 kubelet 上调度执行的 Pod 来授权 kubelet 对 API 的访问。system:node 角色的意义仅是为了与从 v1.8 之前版本升级而来的集群兼容。
system:node-proxier	               system:kube-proxy 用户	                        允许访问 kube-proxy组件所需要的资源。

默认 ClusterRole	                       默认 ClusterRoleBinding	                                           描述
system:auth-delegator	                无	                                 允许将身份认证和鉴权检查操作外包出去。 这种角色通常用在插件式 API 服务器上，以实现统一的身份认证和鉴权。
system:heapster	                        无	                                 为 [Heapster组件（已弃用）定义的角色。
system:kube-aggregator	                无	                                 为 kube-aggregator 组件定义的角色。
system:kube-dns	                        在                                    kube-system 名字空间中的 kube-dns 服务账户	为 kube-dns 组件定义的角色。
system:kubelet-api-admin	            无	                                 允许 kubelet API 的完全访问权限。
system:node-bootstrapper	            无	                                 允许访问执行 kubelet TLS 启动引导所需要的资源。
system:node-problem-detector	        无	                                 为 node-problem-detector 组件定义的角色。
system:persistent-volume-provisioner	无	                                 允许访问大部分动态卷驱动所需要的资源。
system:monitoring	                    system:monitoring 组	                 允许对控制平面监控端点的读取访问（例如：kube-apiserver 存活和就绪端点（/healthz、/livez、/readyz）， 各个健康检查端点（/healthz/*、/livez/*、/readyz/*）和 /metrics）。 请注意，各个运行状况检查端点和度量标准端点可能会公开敏感信息。

system:controller:attachdetach-controller
system:controller:certificate-controller
system:controller:clusterrole-aggregation-controller
system:controller:cronjob-controller
system:controller:daemon-set-controller
system:controller:deployment-controller
system:controller:disruption-controller
system:controller:endpoint-controller
system:controller:expand-controller
system:controller:generic-garbage-collector
system:controller:horizontal-pod-autoscaler
system:controller:job-controller
system:controller:namespace-controller
system:controller:node-controller
system:controller:persistent-volume-binder
system:controller:pod-garbage-collector
system:controller:pv-protection-controller
system:controller:pvc-protection-controller
system:controller:replicaset-controller
system:controller:replication-controller
system:controller:resourcequota-controller
system:controller:root-ca-cert-publisher
system:controller:route-controller
system:controller:service-account-controller
system:controller:service-controller
system:controller:statefulset-controller
system:controller:ttl-controller

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # Rules are automatically filled in by the controller manager.

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: monitoring-endpoints
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
# These rules will be added to the "monitoring" role.
rules:
- apiGroups: [""]
  resources: ["services", "endpoints", "pods"]
  verbs: ["get", "list", "watch"]

[root@k8s-master01 study]# vim a-clusterrole.yaml 
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: test-aggregation
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-test-aggregation: "true"
rules: [] # Rules are automatically filled in by the controller manager.

root@k8s-master01:~/hhh# kubectl get  -f a-clusterrole.yaml -oyaml
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-test-aggregation: "true"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: "2023-12-17T06:26:59Z"
  name: test-aggregation
  resourceVersion: "13622738"
  uid: d71ef7d1-613d-4e4d-ba64-b113352ccb58
rules: null

root@k8s-master01:~# cat test-aggregation-secert.yaml 
apiVersion: v1
kind: Secret
metadata:
  name: test-aggregation
  annotations:
    kubernetes.io/service-account.name: "test-aggregation"   # 这里填写serviceAccountName
type: kubernetes.io/service-account-token

root@k8s-master01:~# kubectl get secrets 
NAME               TYPE                                  DATA   AGE
test-aggregation   kubernetes.io/service-account-token   3      4s
 
 
root@k8s-master01:~#  kubectl describe secret test-aggregation
Name:         test-aggregation
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: test-aggregation
              kubernetes.io/service-account.uid: 6545164e-ddf5-4f16-837a-f5eed1216949
 
Type:  kubernetes.io/service-account-token
 
Data
====
ca.crt:     1310 bytes
namespace:  7 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6ImZtbC13NmNKZVdNOUZWNXhIM3luZmFIT3E2allkV1psb21aVnZWSndDS3MifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InRlc3QtYWdncmVnYXRpb24iLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoidGVzdC1hZ2dyZWdhdGlvbiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjY1NDUxNjRlLWRkZjUtNGYxNi04MzdhLWY1ZWVkMTIxNjk0OSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OnRlc3QtYWdncmVnYXRpb24ifQ.si5ElVz78RG1TQIRu8ZPVLXrrE4-mPZgSpTyY2dlYxqvX16C1oT2bCG7qqQA7E9Hjj606bcxCuUCSPjToFtg6sVhZJ1LKq2vOEdlwyGmaCXJVFlAW1lwWnBl-JLUK0vTBF5sV-X1dlA87k_sD4Yxku7eOtWpnvslXxAZYuoxnx9YH0A5SRL048wWXEW02k2hOmnKo3s8lD0tZKHxtztdjZvppEtBCYbyHZTozI39DcAWyh2nXDYMa0ZPsmTLyfCL_MyJlm4oF8-EQR3yxAy1U6K2GxqqUmkceSdyTh16yyEtUTzjDywzdhmSINUzp8SgXbiSP-RFwzM1VOlRAybRzQ

root@k8s-master01:~#  kubectl get svc kubernetes-dashboard -n kubernetes-dashboard
NAME                   TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
kubernetes-dashboard   NodePort   10.100.184.21   <none>        443:31449/TCP   38d

[root@k8s-master01 study]# vim b-clusterrole.yaml 
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: b-aggregation
  labels:
    rbac.example.com/aggregate-to-test-aggregation: "true"
# These rules will be added to the "monitoring" role.
rules:
- apiGroups: [""]
  resources: ["services", "endpoints", "pods","namespaces"]
  verbs: ["get", "list", "watch"]

root@k8s-master01:~/hhh# kubectl get  -f a-clusterrole.yaml -oyaml
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-test-aggregation: "true"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: "2023-12-17T07:00:02Z"
  name: test-aggregation
  resourceVersion: "13650174"
  uid: ae34eeea-9c4a-4ac9-89b1-cbc56b87ebcc
rules:
- apiGroups:
  - ""
  resources:
  - services
  - endpoints
  - pods
  - namespaces
  verbs:
  - get
  - list
  - watch

[root@k8s-master01 study]# vim namespace-readonly.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: namespace-readonly
rules:
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
 
root@k8s-master01:~/hhh# kubectl create  -f namespace-readonly.yaml
clusterrole.rbac.authorization.k8s.io/namespace-readonly created

[root@k8s-master01 study]# vim pod-delete.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-delete
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - delete
 
[root@k8s-master01 study]# kubectl create -f pod-delete.yaml

[root@k8s-master01 study]# vim pod-exec.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-exec
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
- apiGroups:
  - ""
  resources:
  - pods/exec
  verbs:
  - create
 
[root@k8s-master01 study]# kubectl create -f pod-exec.yaml

[root@k8s-master01 study]# vim pod-log.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-log
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - pods/log
  verbs:
  - get
  - list
  - watch
 
[root@k8s-master01 study]# kubectl create -f pod-log.yaml

root@k8s-master01:~/hhh# cat user1-secert.yaml 
apiVersion: v1
kind: Secret
metadata:
  name: user1
  annotations:
    kubernetes.io/service-account.name: "user1"   # 这里填写serviceAccountName
type: kubernetes.io/service-account-token
root@k8s-master01:~/hhh# cat user2-secert.yaml 
apiVersion: v1
kind: Secret
metadata:
  name: user2
  annotations:
    kubernetes.io/service-account.name: "user2"   # 这里填写serviceAccountName
type: kubernetes.io/service-account-token
 
root@k8s-master01:~/hhh# kubectl create -f user1-secert.yaml -n kube-users 
secret/user1 created
root@k8s-master01:~/hhh# kubectl create -f user2-secert.yaml -n kube-users 
secret/user2 created

root@k8s-master01:~/hhh# kubectl get secret  -n kube-users
NAME    TYPE                                  DATA   AGE
user1   kubernetes.io/service-account-token   3      2m35s
user2   kubernetes.io/service-account-token   3      116s
 
 
root@k8s-master01:~/hhh# kubectl describe secret user1 -n kube-users
Name:         user1
Namespace:    kube-users
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: user1
              kubernetes.io/service-account.uid: 737979b6-9743-4d67-9a63-eeac658d050d
 
Type:  kubernetes.io/service-account-token
 
Data
====
ca.crt:     1310 bytes
namespace:  10 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6ImZtbC13NmNKZVdNOUZWNXhIM3luZmFIT3E2allkV1psb21aVnZWSndDS3MifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXVzZXJzIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InVzZXIxIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6InVzZXIxIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiNzM3OTc5YjYtOTc0My00ZDY3LTlhNjMtZWVhYzY1OGQwNTBkIiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtdXNlcnM6dXNlcjEifQ.VMzHhJV1uQ7mFAluyV7HqE9xOOri1eiHqBlsBDHOTT3pE_8HkTWJWejcmwwUvC9l6qenDbKGJL_Dmyug1DizSyQK8S7fx8-2ezYk0yCnF0GPush2C4GP94RxDYdB42K5zjnPpe14nk-PzjuJgIIg4KhAaTJITuVzvazbh3D8vtM13qrQDUv9vMU6obpdieWx32GeukkXzaSiV_agbvYSTcdmM4ZVLWbikYeZOj5rQQJfKhmD8KQic4iz-tzOvhXkpZFxq_EDUmROJrVI9vsmByvOD3uRckj6Km4KMxHb-MelvxLe6OAsFMKRakrMWLn_1pTh3_I0GiyQ1ZGFXBStwA

root@k8s-master01:~/hhh# kubectl describe secret user2 -n kube-users
Name:         user2
Namespace:    kube-users
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: user2
              kubernetes.io/service-account.uid: d8317d71-6791-4ba7-9fde-dc0f35478d5f
 
Type:  kubernetes.io/service-account-token
 
Data
====
ca.crt:     1310 bytes
namespace:  10 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6ImZtbC13NmNKZVdNOUZWNXhIM3luZmFIT3E2allkV1psb21aVnZWSndDS3MifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXVzZXJzIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InVzZXIyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6InVzZXIyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiZDgzMTdkNzEtNjc5MS00YmE3LTlmZGUtZGMwZjM1NDc4ZDVmIiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtdXNlcnM6dXNlcjIifQ.f3NXQ21CWWl8iH1_ZEmOk01FYRQpM6BonjqD-UobcCzvX3AInzE1db37-wO6LqSfu6-5YfURR7vS8FlL9hN9l0c7ohlsybBHTfTdrPLqsBVhHJ85pJVWpIAMf0k6iGHdsLcS3s1iJHHDpdIIsveYTsM3P40MnvdL1J3goVij5cxqkvB3nM6vxguisLdOzNgAydJMqWXwGdig41Jt9PdvOZm-Fcur1buZzLTZEE3tyHjANFn5VWoDGN_nAw1IB7Ia67DnUeLfpHDnrH9hDmSt029L79YTGL3-lvd_UdRpsd04Vs3fTh9Fs7n_OqOZs5cKz56jmKCiwaY5Pb2LdsX0MQ

[root@k8s-master01 study]# vim  namespace-readonly-sa.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: namespace-readonly-sa
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: namespace-readonly
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts:kube-users
 
 
[root@k8s-master01 study]# kubectl create -f namespace-readonly-sa.yaml

root@k8s-master01:~/hhh# kubectl get svc kubernetes-dashboard -n kubernetes-dashboard
NAME                   TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
kubernetes-dashboard   NodePort   10.100.184.21   <none>        443:31449/TCP   38d

root@k8s-master01:~/hhh# kubectl create rolebinding user1-pod-log --clusterrole=pod-log --serviceaccount=kube-users:user1 --namespace=kube-system
rolebinding.rbac.authorization.k8s.io/user1-pod-log created
root@k8s-master01:~/hhh# kubectl create rolebinding user1-pod-log --clusterrole=pod-log --serviceaccount=kube-users:user1 --namespace=default
rolebinding.rbac.authorization.k8s.io/user1-pod-log created

root@k8s-master01:~/hhh# kubectl create rolebinding user2-pod-exec --clusterrole=pod-exec --serviceaccount=kube-users:user2 --namespace=default
rolebinding.rbac.authorization.k8s.io/user2-pod-exec created
root@k8s-master01:~/hhh#  kubectl create rolebinding user2-pod-delete --clusterrole=pod-delete --serviceaccount=kube-users:user2 --namespace=default
rolebinding.rbac.authorization.k8s.io/user2-pod-delete created