本章目录：

• 1 引言

• 1.1 身份验证 （AuthN） 和授权 （AuthZ）

• 1.2 用于 AuthZ 的 RBAC

• 1.3 Kubernetes 中的 RBAC

• 1.4 此姿势的目的

• 2 RBAC 建模

• 2.2.1 识别 API/URL：引入资源
  

• 2.2.2 识别资源
  上的操作：引入动词
  

• 2.2.3 区分不同
   API 提供程序的资源：引入 API 组
  

• 2.1.1 识别集群外用户/程序：介绍用户
  

• 2.1.2 识别集群内程序客户端：引入服务帐户
  

• 2.1.3 识别多个客户端：引入组
  

• 2.1.4 一般客户推荐：介绍主题
  

• 2.1 客户端建模

• 2.2 服务器端建模

• 2.3 结合动词
  、API组
和资源
  ：引入规则
  

• 2.4 谁拥有规则
  描述的权限：引入角色
  

• 2.5 向目标客户端授予权限：引入角色绑定
  

• 2.6 示例：端到端工作流

• 2.7 小结

• 3 实施

• 3.1 数据结构

• 3.2 引导策略

• 4 讨论

• 4.5.1 普通用户

• 4.5.2 服务帐户用户

• 4.1 无命名空间角色
  /角色绑定
  ：ClusterRole
  /ClusterRole绑定
  

• 4.2 Kubernetes 中的默认角色和集群

• 4.3 将服务帐户信息嵌入到容器中

• 4.4 AuthZ过程的内部

• 4.5 身份验证：区分用户
  和服务帐户的合理性
  

• 4.6 kube-apiserver的相关配置

• 4.7 使 AuthZ YAML 策略更简洁

• 4.8 一些主题示例

• 引用

前言简述：

这篇文章最初出现在RBAC限制对Kubernetes资源的访问中，该帖子经过了精心编辑，重新插图，并通过 learnk8s.io 进行了例证，并且对初学者非常友好。

相比之下，这里发布的版本偏向于设计和实现，以及深入的讨论。

这篇文章深入探讨了 Kubernetes RBAC 授权 （AuthZ） 模型。

具体来说，考虑到向应用程序授予适当访问权限的技术要求，我们将逐步介绍 、kube-apiserver
User
ServiceAccount
Subject
Resource
Verb
APIGroup
Rule
Role
RoleBinding
、等概念，并最终由我们自己的 RBAC 授权模型构建。

希望阅读本文后，读者对kube-apiserver 的访问控制（AuthZ）有更深入的了解。

1 引言

1.1 身份验证 （AuthN） 和授权 （AuthZ）

这两个拼写相似但概念上不同的术语在很长一段时间内使人们感到困惑。总之

• AuthN会检查您是谁（例如，您是否是有效用户）;

• AuthZ 在 AuthN 之后出现，并检查您是否有权执行您声明的操作（例如，写入 spcific 数据库）。

例如，Bob 向服务器发出请求，打算获取 Alice 的数据库列表，GET api/databases?user=alice

然后服务器将按顺序执行以下操作：

1. AuthN：在接收请求时，如果 Bob 是有效用户，请进行身份验证，

1. 验证失败时：通过返回来拒绝请求（长期存在的用词不当，“401 Unauthenticated”会更合适401 Unauthorized
   );

2. 否则（已通过身份验证）：输入下一阶段 （AuthZ）。

2. AuthZ：检查 Bob 是否有权列出 Alice 的数据库，

1. 如果未授予权限，请通过返回403 Forbidden
   ;

2. 否则（已授权），转到真正的处理逻辑。

3. 应用程序处理逻辑：成功或内部服务器错误时返回。2xx
5xx
   

这篇文章将重点介绍授权（AuthZ）。实际上，已经有许多为AuthZ设计的模型，其中包括RBAC（基于角色的访问控制）。

1.2 用于 AuthZ 的 RBAC

RBAC 是一种根据组织中各个用户的角色来调节对服务器端资源的访问的方法。一般的想法是，与其直接将资源访问权限绑定给用户，如下所示，(User,Permission,Resource)

RBAC 引入了 与 中描述的 和 概念，并有助于在具有大量用户权限的大型组织中进行安全管理：Role
RoleBinding
(User,RoleBinding,Role,Permission,Resource)

RBAC不是最近的发明，但可以追溯到几年前。实际上，它是实现强制访问控制（MAC）和自由访问控制（DAC）的一种方法，有关详细信息，请参阅[2，3]。

1.3 Kubernetes 中的 RBAC

K8s 实现了一个 RBAC 模型（以及其他几个模型）来保护群集中的资源。更简单地说，它管理 kube-apiserver 的 API 的权限。通过正确配置的 RBAC 策略，我们可以控制哪些用户（人员或程序）可以通过哪个操作（获取/列表/删除/...）访问哪个资源（pod/services/endpoints/...）。

通过将 --authorization-mode=MODE_LIST
 传递给 来配置群集的授权模式，其中是一个以逗号分隔的列表，其中包含以下有效值：RBAC/ABAC/Node/AlwaysDeny/AlwaysAllow
。kube-apiserver
MODE_LIST

有关更多信息，请参阅 Kubernetes 文档授权概述 [1]。

举个例子，如果你已经玩了一段时间的Kubernetes，你会看到这样的东西：

apiVersion: v1kind: ServiceAccountmetadata:  name: serviceaccount:app1  namespace: demo-namespace----apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:  name: role:viewer  namespace: demo-namespacerules:        # Authorization rules for this role- apiGroups:  # 1st API group  - ""        # An empty string designates the core API group.  resources:  - services  - endpoints  - namespaces  verbs:  - get  - list  - watch- apiGroups:  # 2nd API group  - apiextensions.k8s.io  resources:  - customresourcedefinitions  verbs:  - get  - list  - watch- apiGroups:  # 3rd API group  - cilium.io  resources:  - ciliumnetworkpolicies  - ciliumnetworkpolicies/status  verbs:  - get  - list  - watch----apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: rolebinding:app1-viewer  namespace: demo-namespaceroleRef:  apiGroup: rbac.authorization.k8s.io  kind: Role  name: role:viewersubjects:- kind: ServiceAccount  name: serviceaccount:app1  namespace: demo-namespace

这只是Kubernetes的RBAC语言中的一个权限声明，应用后，它将创建：

1. 服务（程序）的帐户，

2. 角色及其拥有的权限，以及

3. 一种角色绑定，用于将帐户绑定到该角色，以便该服务中的程序可以访问 的资源（例如，列表命名空间）。kube-apiserver
   

1.4 此姿势的目的

这篇文章将通过自己设计来深入研究Kubernetes中的RBAC模型。

具体而言，给定以下要求：向群集中的应用程序 （） 授予以下 API 的读取 （） 权限：get/list/watch
kube-apiserver
app1

# 1. Kubernetes builtin resources/api/v1/namespaces/{namespace}/services/api/v1/namespaces/{namespace}/endpoints/api/v1/namespaces/{namespace}/namespaces# 2. A specific API extention provided by cilium.io/apis/cilium.io/v2/namespaces/{namespace}/ciliumnetworkpolicies/apis/cilium.io/v2/namespaces/{namespace}/ciliumnetworkpolicies/status

让我们看看如何设计一个玩具模型来满足这些要求。

2 RBAC 建模

在 Kubernetes 中，授权是针对来自经过身份验证的客户端的传入请求的服务器端权限检查过程。在本节的其余部分中，我们将把建模工作分成几个部分：

1. 客户端：客户端识别和代表;

2. 服务器端：资源（API）表示和组织;

3. 权限组织和管理。

2.1 客户端建模

让我们从最简单的情况开始，然后逐步介绍复杂的情况。

2.1.1 识别集群外用户/程序：简介User

第一种情况：假设您的新同事想要登录 Kubernetes 仪表板，或使用 CLI。对于此方案，我们应该在模型中有一个概念来表示什么是“帐户”或“用户”，每个帐户都有唯一的名称或 ID（例如电子邮件地址），如下所示：

type User struct {    name string   // unique for each user    ...           // other fields}

然后，我们可以在 YAML 文件中引用具有类似以下内容的用户：

- kind: User  name: "alice@example.com"

请注意，这里介绍的概念用于集群外部的人或进程（与下一个将要描述的概念相反，后者标识了由Kubernetes本身创建和管理的帐户）。例如，用户帐户可能来自组织中的 LDAP，因此可以通过 OAuth2、TLS 证书、令牌等方式完成用户的身份验证;随后的AuthZ流程将与ServiceAccount客户端相同。User
ServiceAccount

2.1.2 识别集群内程序客户端：简介ServiceAccount

大多数时候，访问 kube-apiserver 的是 Kubernetes 集群中的应用程序，而不是人类用户，例如

• cilium-agent
  作为网络代理（部署为守护程序集）想要列出特定节点上的所有 pod 资源，

• ingress-nginx-controller
  作为 L7 网关，希望列出特定服务的所有后端终结点，

由于这些应用程序是由 Kubernetes 创建和管理的，因此我们对它们的身份负责。因此，我们引入了ServiceAccount（SA），这是Kubernetes集群中应用程序的命名空间帐户，就像公司中员工的人工帐户一样。

由于 SA 是应用程序级帐户，因此应用程序的所有 Pod 都共享 SA，因此具有完全相同的权限。SA 被引入并将存储在 Kubernetes 中，因此我们可以使用以下 YAML 规范定义一个 ServiceAccount：

apiVersion: v1kind: ServiceAccountmetadata:  name: sa:app1             # arbitrary but unique string  namespace: demo-namespace

我们无法定义 a，因为它们由 Kubernetes 外部的外部系统（如 LDAP 或 AD）管理。相反，我们只能引用 s。User
User

然后引用它：

- kind: ServiceAccount  name: sa:app1  namespace: demo-namespace

2.1.3 识别多个客户端：引入Group

为了便于 Kubernetes 管理，我们最好也支持一组 Users 或 ServiceAccounts

例如，借助此功能，我们可以引用特定命名空间中的所有服务帐户：

- kind: Group  name: system:serviceaccounts  namespace: demo-namespace

2.1.4 一般客户参考：介绍Subject

随着几种客户端类型的引入，我们现在准备为它们引入一个通用容器：。主题列表可以包含不同类型的客户端类型，例如Subject

subjects:- kind: User  name: "alice@example.com"- kind: ServiceAccount  name: default  namespace: kube-system

这使我们的政策更具表现力和影响力。

完成客户端识别后，让我们看看服务器端。

2.2 服务器端建模

服务器端部分更复杂，因为这是我们必须处理授权和身份验证的地方。

同样，我们从最小的单位开始。

2.2.1 识别 API/URL：简介Resource

Kubernetes 集群中的 Pod、端点、服务等对象通过内置的 API/URI 公开，例如：

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

这些 URI 太长，无法在 AuthZ 策略规范中简明扼要地描述，因此我们引入了一个简短的表示形式：。使用表示法，上述 API 可以通过以下方式引用：Resource
Resource

  resources:  - pods  - pods/log  - serviceaccounts

2.2.2 识别操作：介绍Resource
Verb

为了描述对给定的允许操作，例如，无论是只读（）还是写-更新-删除（），我们引入了一个概念：Resource
get/list/watch
create/patch/delete
Verb

  resources:  - ciliumnetworkpolicies  - ciliumnetworkpolicies/status  verbs:  - get  - list  - watch

2.2.3 区别于不同的 API 提供商：简介Resource
APIGroup

在本节中，我们有意跳过了讨论的一件事：除了内置对象（pod、端点、服务等）的 API 之外，Kubernetes 还支持 API 扩展。例如，如果使用 Cilium 作为网络解决方案，它将在集群中创建“ciliumendpoint”自定义资源 （CR），Resource

apiVersion: apiextensions.k8s.io/v1kind: CustomResourceDefinitionmetadata:  name: ciliumendpoints.cilium.iospec:  group: cilium.io  names:    kind: CiliumEndpoint  scope: Namespaced  ...

检查集群中已有的相关对象：

$ k get ciliumendpoints.cilium.io -n demo-namespaceNAME   ENDPOINT ID   IDENTITY ID   INGRESS ENFORCE  EGRESS ENFORCE VISIBILITY POLICY   ENDPOINT STATE   IPV4app1   2773          1628124                                                           ready            10.6.7.54app2   3568          1624494                                                           ready            10.6.7.94app3   3934          1575701                                                           ready            10.6.4.24

这些自定义资源对象可以采用与内置对象类似的 URI 格式进行访问，

/apis/cilium.io/v2/namespaces/{namespace}/ciliumendpoints/apis/cilium.io/v2/namespaces/{namespace}/ciliumendpoints/{name}

因此，为了使我们的短格式资源表示更通用，我们也需要支持此方案。进入apiGroups。顾名思义，将 API（资源）拆分为多个组。在我们的设计中，我们只是将资源和相关动词放入一个部分：APIGroup
APIGroup

- apiGroups:  - cilium.io     # APIGroup name  resources:  - ciliumnetworkpolicies  - ciliumnetworkpolicies/status  verbs:  - get  - list  - watch

根据 API 组的“名称”，

• 如果为空，则将资源展开为/api/v1/xxx
  ;

• 否则，我们会将资源扩展到/apis/{apigroup_name}/{apigroup_version}/xxx
  ;

如下图所示：

2.3 结合 和 ：介绍Verb
APIGroup
Resource
Rule

正如最后一篇文章所介绍的那样，我们终于可以描述什么是AuthZ规则
：实际上，APIGroups它只不过是一个允许访问的apiGroup列表

rules:        # Authorization rules- apiGroups:  # 1st API group  - ""        # An empty string designates the core API group.  resources:  - services  - endpoints  - namespaces  verbs:  - get  - list  - watch- apiGroups:  # another API group  - cilium.io # Custom APIGroup  resources:  - ciliumnetworkpolicies  - ciliumnetworkpolicies/status  verbs:  - get  - list  - watch

如下图所示：

2.4 谁拥有规则描述的权限：介绍角色

准备好“规则”和“主题”后，我们可以将“规则”分配给“主题”，然后所描述的主题客户端将有权访问规则中描述的资源。但如前所述，RBAC 的特征是 ，它将单个用户与单个规则分离，并使特权共享和授予更加强大且可管理。Roles

因此，我们不是直接将规则插入到主题（帐户/服务帐户）中，而是将其插入到角色中：

apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:  name: viewerrules:- apiGroups:  # 1st API group  - ""        # An empty string designates the core API group.  resources:  - pods  verbs:  - get  - list  - watch  - delete- apiGroups:  ...

请注意，我们在 Kubernetes 中引入了一种资源，因此在这里我们在 yaml 中有一个字段，而 ，只是内部概念（和数据结构）。Role
apiVersion
Resource
APIGroup
Verb

2.5 向目标客户端授予权限：简介RoleBinding

现在，我们必须引用各种客户端，以描述允许的资源，以及描述哪些不同类型的规则，我们最后一件事是将目标客户端绑定到特定角色。进入。Subject
Rule
Role
RoleBinding

角色绑定将 a 中描述的权限授予一个或多个客户端。它包含 s（用户、组或服务帐户）的列表，以及对所授予的角色的引用。Role
Subject

例如，要将角色绑定到主题，viewer
kind=ServiceAccount,name=sa-for-app1,namespace=demo-namespace

apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: role-binding-for-app1               # RoleBinding nameroleRef:  apiGroup: rbac.authorization.k8s.io  kind: Role  name: viewer                              # Role to be referredsubjects:                                   # Clients that will be binded to the above Role- kind: ServiceAccount  name: sa-for-app1  namespace: kube-system

注意，这也是作为一种 Kubernetes 资源引入的，所以它有字段。RoleBinding
apiVersion

2.6 示例：端到端工作流

现在我们的 RBAC 建模完成了，让我们看一个端到端的工作流程：如何设置 Kubernetes RBAC 内容，以允许应用程序在集群中列出 ciliumnetworkpolicies
 资源。

1. 群集管理员：为应用程序创建服务帐户app1
   ;

2. 群集管理员：创建一个角色来描述允许对特定资源的权限;

3. 集群管理员：创建角色绑定，将服务账号绑定到角色;

4. 客户端：向 kube-apiserver 发送请求，例如列出特定命名空间中的所有;ciliumnetworkpolicies
   

5. kube-apiserver
    身份验证：验证用户;在经过身份验证时，将服务帐户关联到角色，转至 6;

6. kube-apiserver
    AuthZ：检查权限（如角色>规则>API组）中所述）;在授权上，转到7;

7. kube-apiserver
   ：处理请求，检索给定命名空间中的所有内容;ciliumnetworkpolicies
   

8. kube-apiserver
   ：将结果返回给客户端。

请注意，如果 AuthN 或 AuthZ 失败，kube-apiserver 将直接返回并显示正确的错误消息。此外，我们还在执行 RoleBinding 时在主题列表中绘制了一个人类用户，当客户端是集群外用户或程序时，就是这种情况。

2.7 小结

毫不奇怪，我们设计的RBAC模型是Kubernetes（rbac.authorization.k8s.io
 API）附带的简化版本。希望通过这种自下而上的方法，你对 RBAC 模型和相关概念有了更好的了解。

在下一节中，我们将快速了解 Kubernetes 中的 RBAC 实现。

3 实施

3.1 数据结构

在不使这篇文章太长的情况下，我们只是指出一些关键的数据结构：

// https://github.com/kubernetes/kubernetes/blob/v1.23.4/pkg/apis/rbac/types.go// PolicyRule holds information that describes a policy rule, but does not contain information// about who the rule applies to or which namespace the rule applies to.type PolicyRule struct {    Verbs     []string    APIGroups []string    Resources []string    // Following types not covered in this post    ResourceNames   []string    NonResourceURLs []string}// Subject contains a reference to the object or user identities a role binding applies to.  This can either hold a direct API object reference,// or a value for non-objects such as user and group names.type Subject struct {    Kind string    APIGroup string    Namespace string}// RoleRef contains information that points to the role being usedtype RoleRef struct {    APIGroup string // APIGroup is the group for the resource being referenced    Kind string // Kind is the type of resource being referenced    Name string // Name is the name of resource being referenced}// Role is a namespaced, logical grouping of PolicyRules that can be referenced as a unit by a RoleBinding.type Role struct {    Rules []PolicyRule}// RoleBinding references a role, but does not contain it.  It can reference a Role in the same namespace or a ClusterRole in the global namespace.// It adds who information via Subjects and namespace information by which namespace it exists in.  RoleBindings in a given// namespace only have effect in that namespace.type RoleBinding struct {    Subjects []Subject    RoleRef RoleRef}

3.2 引导策略

一些内置角色、规则等：

// https://github.com/kubernetes/kubernetes/blob/v1.23.4/plugin/pkg/auth/authorizer/rbac/bootstrappolicy/policy.go

4 讨论

4.1 无命名空间 ：Role
RoleBinding
ClusterRole
/ClusterRoleBinding

设置特定命名空间内的权限。如果要设置无命名空间角色，可以使用（以及相应的 ）。Role
ClusterRole
ClusterRoleBinding

在perticular中，一些Kubernetes资源不是命名空间范围的，例如Persistent Volumes和Nodes。

/api/v1/nodes/{name}/api/v1/persistentvolume/{name}

kube-apiserver
创建一组默认的 ClusterRole/ClusterRoleBinding 对象，

• 其中许多是系统：
  前缀，表示资源由集群控制平面直接管理;

• 所有默认的 ClusterRoles 和 ClusterRoleBinding 都标有 kubernetes.io/bootstrapping=rbac-defaults
  。

4.2 Kubernetes 中的默认角色和集群

默认角色：

$ k get roles -n kube-system | grep "^system:"NAME                                             CREATED ATsystem::leader-locking-kube-controller-manager   2021-05-10T08:52:46Zsystem::leader-locking-kube-scheduler            2021-05-10T08:52:46Zsystem:controller:bootstrap-signer               2021-05-10T08:52:45Zsystem:controller:cloud-provider                 2021-05-10T08:52:45Zsystem:controller:token-cleaner                  2021-05-10T08:52:45Z...

默认集群区域：

$ kubectl get clusterroles -n kube-system | grep "^system:"system:aggregate-to-admin                               2021-05-10T08:52:44Zsystem:aggregate-to-edit                                2021-05-10T08:52:44Zsystem:aggregate-to-view                                2021-05-10T08:52:44Zsystem:discovery                                        2021-05-10T08:52:44Zsystem:kube-apiserver                                   2021-05-10T08:57:10Zsystem:kube-controller-manager                          2021-05-10T08:52:44Zsystem:kube-dns                                         2021-05-10T08:52:44Zsystem:kube-scheduler                                   2021-05-10T08:52:44Z...

要查看每个角色/集群中的详细权限，

$ kubectl get role <role> -n kube-system -o yaml

4.3 将服务帐户信息嵌入到容器中

服务帐户通常由 API 服务器自动创建，并与集群中运行的 Pod 相关联。三个独立的组件协同实现自动化：

1. 一个服务账户准入控制器，实现

   准入控制模块可以修改或拒绝请求。除了授权模块可用的属性外，它们还可以访问正在创建或修改的对象的内容，例如，将访问令牌注入 Pod。

2. 令牌控制器

3. 服务帐户控制器

服务帐户持有者令牌在集群外部使用是完全有效的，可用于为希望与 Kubernetes API 通信的长期作业创建标识。若要手动创建服务帐户，

$ kubectl create serviceaccount demo-saserviceaccount/demo-sa created$ k get serviceaccounts demo-sa -o yamlapiVersion: v1kind: ServiceAccountmetadata:  name: demo-sa  namespace: default  resourceVersion: "1985126654"  selfLink: api/v1/namespaces/default/serviceaccounts/demo-sa  uid: 01b2a3f9-a373-6e74-b3ae-d89f6c0e321fsecrets:- name: demo-sa-token-hrfq2

创建的密钥保存 API 服务器的公共 CA 和已签名的 JSON Web 令牌 （JWT）。

$ kubectl get secret demo-sa-token-hrfq2 -o yamlapiVersion: v1data:  ca.crt: (APISERVER CA BASE64 ENCODED)  namespace: ZGVmYXVsdA==  token: (BEARER TOKEN BASE64 ENCODED)kind: Secretmetadata:  # ...type: kubernetes.io/service-account-token

已签名的 JWT 可用作持有者令牌，以作为给定的服务帐户进行身份验证，并包含在请求标头中。通常，这些密钥会挂载到 Pod 中，以便在集群内访问 API 服务器，但也可以从集群外部使用。

服务帐户使用用户名 system：serviceaccount：NAMESPACE：SERVICEACCOUNT
 进行身份验证，并分配给组 system：serviceaccounts
 和 system：serviceaccounts：NAMESPACE
。

4.4 AuthZ过程的内部

有关授权过程的更多信息，请参阅 Kubernetes 文档授权概述。

4.5 认证：区分和User
ServiceAccount

Kubernetes 集群有两类用户 [4]：

1. 服务帐户：由 Kubernetes 管理，

2. 普通用户：通常由独立于集群的服务通过以下方式进行管理：

• 分发私钥的管理员

• 像 Keystone 或 Google 帐号这样的用户商店

• 包含用户名和密码列表的文件

4.5.1 普通用户

在这方面，Kubernetes 没有表示普通用户帐户的对象。普通用户无法通过 API 调用添加到集群。但是，任何提供有效凭据的用户都被视为已通过身份验证。

有关更多详细信息，请参阅证书请求中的普通用户主题，以获取有关此内容的更多详细信息。

4.5.2 服务帐户用户

相比之下，服务帐户是由 Kubernetes API 管理的用户。他们是，

• 由 API 服务器自动创建或通过 API 调用手动创建。

• 绑定到一组存储为 的凭证，这些凭证被挂载到 pod 中，允许集群内进程与 Kubernetes API 通信。Secrets
  

幕后的更多理性，请参阅 Kubernetes 文档 用户帐户与服务帐户。

4.6 kube-apiserver的相关配置

$ cat etc/kubernetes/apiserver.config --authorization-mode=Node,RBAC \ --kubelet-certificate-authority=/etc/kubernetes/pki/ca.crt \ --service-account-key-file=/etc/kubernetes/pki/sa.pub        # bearer tokens. If unspecified, the API server's TLS private key will be used. ...

4.7 使 AuthZ YAML 策略更简洁

正常规格：

rules:- apiGroups:  - ""  resources:  - pods  - endpoints  - namespaces  verbs:  - get  - watch  - list  - create  - delete

上述规范可以按以下格式重写：

- apiGroups: [""]  resources: ["services", "endpoints", "namespaces"]  verbs:     ["get", "list", "watch", "create", "delete"]

这大大减少了线条，并且更加简洁。但 Kubernetes 内部仍然使用长格式管理内容：

$ kubectl get role pod-reader -o yamlapiVersion: rbac.authorization.k8s.io/v1kind: Rolerules:- apiGroups:  - ""  resources:  - pods...

4.8 一些主题示例

subjects:- kind: Group  name: system:serviceaccounts:qa  apiGroup: rbac.authorization.k8s.iosubjects:- kind: Group  name: system:serviceaccounts         # when namespace field is no specified: all service accounts in any namespace  apiGroup: rbac.authorization.k8s.iosubjects:- kind: Group  name: system:authenticated           # for all authenticated users  apiGroup: rbac.authorization.k8s.io- kind: Group  name: system:unauthenticated         # for all unauthenticated users  apiGroup: rbac.authorization.k8s.io

引用

1. Kubernetes Doc：Authorization Overview

2. 维基百科：RBAC

3. RBAC 的本意

4. Kubernetes Doc：Authentication Overview

本文至此完毕，更多技术文章，尽情期待下一章节！

更多文章来源于【WeiyiGeek Blog 个人博客 - 为了能到远方，脚下的每一步都不能少 】

个人主页: 【 https://weiyigeek.top】

博客地址: 【 https://blog.weiyigeek.top 】

专栏书写不易，如果您觉得这个专栏还不错的，请给这篇专栏 【点个赞、投个币、收个藏、关个注，转个发，留个言】(人间六大情)，这将对我的肯定，谢谢！。

• echo  "【点个赞】，动动你那粗壮的拇指或者芊芊玉手，亲！"

• printf("%s", "【投个币】，万水千山总是情，投个硬币行不行，亲！")

• fmt.Printf("【收个藏】，阅后即焚不吃灰，亲！")  

• console.info("【转个发】，让更多的志同道合的朋友一起学习交流，亲！")

• System.out.println("【关个注】，后续浏览查看不迷路哟，亲！")

• cout << "【留个言】，文章写得好不好、有没有错误，一定要留言哟，亲! " << endl;

 往期相关文章

更多网络安全、系统运维、应用开发、全栈文章，尽在【个人博客 - https://blog.weiyigeek.top】站点，谢谢支持！

↓↓↓ 更多文章，请点击下方阅读原文。

温馨提示: 文章转载自【破解 Kubernetes RBAC 授权模型 (arthurchiao.art) -  http://arthurchiao.art/blog/cracking-k8s-authz-rbac/ 】，

原作者为【arthurchiao】，如果涉嫌侵权，请发送邮件至【master@weiyigeek.top 】进行举报，博主将立刻删除相关内容。