使用 RBAC 鉴权

基于角色（Role）的访问控制（RBAC）是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法。

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

要启用 RBAC，在启动 API 服务器时将 --authorization-config 标志设置为包含 RBAC 授权者的文件； 例如：

apiVersion: apiserver.config.k8s.io/v1
kind: AuthorizationConfiguration        #授权配置清单
authorizers:
  ...
  - type: RBAC                          #启用RBAC授权器
  ...

或者，启动 API 服务器时， 将 --authorization-mode 标志设置为包含 RBAC 的逗号分隔列表； 例如：

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

API 对象

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

Role 和 ClusterRole

RBAC 的 Role 或 ClusterRole 中包含一组代表相关权限的规则，这些权限是纯粹累加的

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

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

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

1. 定义对名称空间作用域资源的访问权限，并将在个别名称空间内被授予访问权限；

2. 定义对名称空间作用域资源的访问权限，并被授予跨所有名称空间的访问权限；

3. 为集群作用域的资源定义访问权限。

#使用该命令查属于名称空间作用域资源

kubectl api-resources --namespaced=true

如果你希望在名称空间内定义角色，应该使用Role；如果你希望定义集群范围的角色，应该使用ClusterRole。

Role 示例

下面是一个位于 default 命名空间中的 Role 示例，可用于授予对 Pod 的只读访问权限。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default         #需指定名称空间
  name: pod-reader
rules:
- apiGroups: [""]                  # "" 标明 core API 组
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRole 示例

ClusterRole 同样可以用于授予 Role 能够授予的权限，因为 ClusterRole 属于集群范围，所以它也可以为以下资源授予访问权限：

• 集群范围资源（比如节点（Node））
• 非资源端点（比如 "/healthz"）
• 跨名称空间访问的名称空间作用域的资源（如 Pod）

下面是一个 ClusterRole 的示例，可用来为任一特定名称空间的 Secret 授予读访问权限，或者跨名称空间的访问权限（取决于该角色是如何绑定的）

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

RoleBinding 和 ClusterRoleBinding

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

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

RoleBinding 示例

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

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

RoleBinding 也可以引用 ClusterRole，以将对应 ClusterRole 中定义的访问权限授予 RoleBinding 所在名称空间的资源。这种引用使得你可以跨整个集群定义一组通用的角色，之后再多个名称空间复用

例如，尽管下面的 RoleBinding 引用的是一个 ClusterRole，但是 "dave" （这里的主体，区分大小写）只能访问 "developmnet" 名称空间中的 Secret 对象，因为 RoleBinding 所在的名称空间（由其 metadata 决定）是"development"。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-secrets
  # RoleBinding 的名称空间决定了访问权限的授予范围。
  # 这里隐含授权仅在 "development" 名称空间内的访问权限。
  namespace: development
subjects:
- kind: User
  name: dave           # 'name' 是区分大小写的
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding 示例

要跨整个集群完成访问权限的授予，可以使用一个 ClusterRoleBinding。下面的 ClusterRoleBinding 允许 "manager" 组内的所有用户访问任何名称空间中的 Secret。

apiVersion: rbac.authorization.k8s.io/v1
# 此集群角色绑定允许 “manager” 组中的任何人访问任何名称空间中的 Secret 资源
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager      # 'name' 是区分大小写的
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

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

命令  kubectl auth reconcile 可以创建或者更新包含 RBAC 对象的清单文件， 并且在必要的情况下删除和重新创建绑定对象，以改变所引用的角色。

对资源的引用

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

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

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

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

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

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

你可以使用通配符 * 批量引用所有的 resources、apiGroups 和 verbs 对象，无需逐一引用。 对于 nonResourceURLs，你可以将通配符 * 作为后缀实现全局通配， 对于 resourceNames，空集表示没有任何限制。 下面的示例对 example.com API 组中所有当前和未来资源执行所有动作。 这类似于内置的 cluster-admin。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: example.com-superuser # 此角色仅作示范，请勿使用
rules:
- apiGroups: ["example.com"]
  resources: ["*"]
  verbs: ["*"]

Role 示例

以下示例均为从 Role 或 ClusterRole 对象中截取出来，仅展示其 rules 部分。

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

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

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

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

允许读取核心 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"]

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

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

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

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

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

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

对主体的引用

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

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

在 Kubernetes 中，身份认证（Authenticator）模块提供用户组信息。 与用户名一样，用户组名也用字符串来表示，而且对该字符串没有格式要求， 只是不能使用保留的前缀 system:。

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

RoleBinding 示例

下面示例是 RoleBinding 中的片段，仅展示其 subjects 的部分。

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

subjects:
- kind: User
  name: "alice@example.com"
  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

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

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:authenticated
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

默认 Roles 和 Role Bindings

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

自动协商

在每次启动时，API服务器都会更新默认 ClusterRole 以添加缺失的各种权限，并更新默认的 ClusterRoleBinding 以增加缺失的各类主体。这种自动协商机制允许集群去修复一些不小心发生的修改，并且有助于报证 "roles" 和 "role bindings" 在新的发行版中有权限或主体变更时仍然保持最新。

如果要禁止此功能，请将默认 ClusterRole 以及 ClusterRoleBinding 的 rbac.authorization.kubernetes.io/autoupdate 注解设置成 false。注意，缺少默认权限和角色绑定主体可能会导致集群无法正常工作。

API 发现角色

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

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

kubectl get clusterroles system:discovery -o yaml

默认 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 版本中引入的。

面向用户的角色

一些默认的 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 进行写操作。 更多信息参阅 “EndpointSlices 写权限”小节。
edit	无	允许对名称空间的大多数对象进行读/写操作。此角色不允许查看或者修改角色或者角色绑定。 不过，此角色可以访问 Secret，以名称空间中任何 ServiceAccount 的身份运行 Pod， 所以可以用来了解名称空间内所有服务账户的 API 访问级别。 此角色也不允许对 Kubernetes v1.22+ 创建的 EndpointSlices 进行写操作。 更多信息参阅 “EndpointSlices 写操作”小节。
view	无	允许对名称空间的大多数对象有只读权限。 它不允许查看角色或角色绑定。此角色不允许查看 Secret，因为读取 Secret 的内容意味着可以访问名称空间中 ServiceAccount 的凭据信息，进而允许利用名称空间中任何 ServiceAccount 的身份访问 API（这是一种特权提升）。

核心组件角色

默认 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 组件所需要的资源。

初始化与预防权限提升

RBAC API 会阻止用户通过编辑角色或者角色绑定来提升权限。 由于这一点是在 API 级别实现的，所以在 RBAC 鉴权组件未启用的状态下依然可以正常工作。

对角色创建或更新的限制

只有在符合下列条件之一的情况下，你才能创建/更新角色:

1. 你已经拥有角色中包含的所有权限，且其作用域与正被修改的对象作用域相同。 （对 ClusterRole 而言意味着集群范围，对 Role 而言意味着相同名称空间或者集群范围）。

2. 你被显式授权在 rbac.authorization.k8s.io API 组中的 roles 或 clusterroles 资源使用 escalate 动词。

例如，如果用户 user-1 不具备在集群范围内查看（list）Secrets 的权限，那么该用户就不能创建一个包含此项权限的 ClusterRole（集群角色）。要允许用户创建或更新角色，需要执行以下操作：

1. 根据需要赋予他们一个角色，允许他们根据需要创建/更新 Role 或者 ClusterRole 对象。

2. 授予他们权限，使其能够在所创建或更新的角色中包含特定的权限

对角色绑定创建或更新的限制

只有你已经具有了所引用的角色中包含的全部权限时，或者你被授权在所引用的角色上执行 bind 动词时，你才可以创建或更新角色绑定。这里的权限与角色绑定的作用域相同。 例如，如果用户 user-1 没有列举集群范围所有 Secret 的能力，则他不可以创建 ClusterRoleBinding 引用授予该许可权限的角色。 如要允许用户创建或更新角色绑定：

1. 赋予他们一个角色，使得他们能够根据需要创建或更新 RoleBinding 或 ClusterRoleBinding 对象。
2. 授予他们绑定某特定角色所需要的许可权限：

例如，下面的 ClusterRole 和 RoleBinding 将允许用户 user-1 把名称空间 user-1-namespace 中的 admin、edit 和 view 角色赋予其他用户：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: role-grantor
rules:
- apiGroups: ["rbac.authorization.k8s.io"]                 #允许创建RoleBinding资源
  resources: ["rolebindings"]
  verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]                 #允许绑定指定的ClusterRole资源
  resources: ["clusterroles"]
  verbs: ["bind"]
  # 忽略 resourceNames 意味着允许绑定任何 ClusterRole
  resourceNames: ["admin","edit","view"]                   #白名单：只允许绑定这3个系统内置集群内角色
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: role-grantor-binding
  namespace: user-1-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: role-grantor
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: user-1

当启动引导第一个角色和角色绑定时，需要为初始用户授予他们尚未拥有的权限。 对初始角色和角色绑定进行初始化时需要：

• 使用用户组为 system:masters 的凭据，该用户组由默认绑定关联到 cluster-admin 这个超级用户角色。

一些命令行工具

kubectl create role

创建 Role 对象，定义在某一个名称空间中的权限，例如：

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

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

创建名称为"pod-reader"的 Role 对象并指定 resourceNames:

kubectl create role pod-reader --resource=pods  --verb=get --resource-name=testpod

创建名为"foo"的 Role 对象并指定apiGroups:

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

创建名称为"foo"的 Role 对象并指定子资源权限

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

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

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

kubectl create clusterrole

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

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

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

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

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

kubectl create clusterrole foo --resource=replicas.apps --verb=get,list,wach

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

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

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

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

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

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

kubectl create rolebinding

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

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

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

kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=amce:myapp --namespaced=acme

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

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

kubectl create clusterrolebinding

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

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

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

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

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

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

kube auth reconcile

从清单文件中创建或更新 rbac.authorization.k8s.io/v1 版本的 RBAC API 对象。

若目标对象不存在则执行创建操作；对于名称空间级 RBAC 对象，其所属的名称空间如需创建会被自动新建。

对已存在的角色：将清单文件中的权限规则合并追加至该角色中；若指定了 --remove-extra-permissions 参数，则会移除该角色中超出清单文件定义的多余权限规则。

对已存在的绑定关系：将清单文件中的主体对象合并追加至该绑定中；若指定了 --remove-extra-subjects 参数，则会移除该绑定中超出清单文件定义的多余主体对象。

例如：

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

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

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

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

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

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

服务账号权限

默认的 RBAC 策略为控制面组件、节点和控制器授予权限。 但是不会对 kube-system 名称空间之外的服务账户授予权限。 （除了 API 发现角色 授予的权限）

这使得你可以根据需要向特定 ServiceAccount 授予特定权限。 细粒度的角色绑定可带来更好的安全性，但需要更多精力管理。 粗粒度的授权可能导致 ServiceAccount 被授予不必要的 API 访问权限（甚至导致潜在的权限提升）， 但更易于管理。

例如：

在名称空间 “my-namespace” 中授予服务账户 “my-sa” 只读权限：

kubectl create rolebinding my-sa-view --clusterrole=view --serviceaccount=my-namespace:my-sa --namespace=my-namespace

在名称空间 "my-namespace" 中授予服务账户 "default" 只读权限：

kubectl create rolebinding default-view --clusterrole=view --serviceaccount=my-namespace:default --namespace=my-namespace

在名称空间 “my-namespace” 中的只读权限授予该名称空间中的所有服务账户：

kubectl create rolebingding serviceaccount-view --clusterrole=view --serviceaccount=system:serviceaccounts:my-namespace --namesapce=my-namespace

为集群范围的所有服务账户授予跨所有名称空间的只读权限：

kubectl create clusterrolebinding serviceaccount-view --clusterrole=view --group=system:serviceaccounts