一、RBAC配置示例¶

1.1 Role示例¶

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

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

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

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

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

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

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

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

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

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

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

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

1.2 RoleBinding示例¶

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

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

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

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

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

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

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

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

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

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

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

上面参数说明:

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

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

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

上面参数说明:

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

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

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

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

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

8.对于所有用户：

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

二、RBAC角色分类¶

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

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

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

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

kubectl get clusterroles system:discovery -o yaml

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

默认 ClusterRole	默认 ClusterRoleBinding	描述
system:basic-user	system:authenticated 组	允许用户以只读的方式去访问他们自己的基本信息。在 v1.14 版本之前，这个角色在默认情况下也绑定在 `system:unauthenticated` 上。
system:discovery	system:authenticated 组	允许以只读方式访问 API 发现端点，这些端点用来发现和协商 API 级别。在 v1.14 版本之前，这个角色在默认情况下绑定在 `system:unauthenticated` 上。
system:public-info-viewer	system:authenticated 和 system:unauthenticated 组	允许对集群的非敏感信息进行只读访问，此角色是在 v1.14 版本中引入的。

2.1 面向用户的角色¶

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

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

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（这是一种特权提升）。

2.2 核心组件角色¶

默认 ClusterRole	默认 ClusterRoleBinding	描述
system:kube-scheduler	system:kube-scheduler 用户	允许访问 scheduler组件所需要的资源。
system:volume-scheduler	system: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组件所需要的资源。

2.3 其他组件角色¶

默认 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`）。请注意，各个运行状况检查端点和度量标准端点可能会公开敏感信息。

2.4 内置控制器的角色¶

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

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

RBAC配置示例与角色分类