kubernetes RBAC相遇--介绍常规用法集群默认 _KUBERNETES

寸阳分阴须爱惜，休负春色与时光。这篇文章主要讲述kubernetes RBAC相遇--介绍常规用法集群默认相关的知识，希望能为你提供帮助。

文章目录

??1. 简介??
??2. API 对象??

??2.1 角色（Role）??
??2.2 集群角色（ClusterRole）??
??2.3 角色绑定（RoleBinding）和集群角色绑定（ClusterRoleBinding）??

??3. 对资源的引用??
??4. 聚合的 ClusterRole??
??5. Role 示例??
??6. 对主体的引用??
??7. RoleBinding 示例??
??8. 默认 Roles 和 Role Bindings??
??9. 面向用户的角色??
??10. 核心组件角色??
??11. 其他组件角色??
??12. 内置控制器的角色??
??13. 对角色绑定创建或更新的限制??
??14. 命令行工具??

??14.1 kubectl create role??
??14.2 kubectl create clusterrole??
??14.3 kubectl create rolebinding??
??14.4 kubectl create clusterrolebinding??
??14.5 kubectl auth reconcile??

??15. 服务账号权限??
??16. 宽松的 RBAC 权限??
??17. 示例??

??容器网络接口（CNI）weavework??

1. 简介RBAC（Role-Based Access Control，基于角色的访问控制）在Kubernetes的??1.5???版本中引入，在??1.6???版本时升级为??Beta???版本，在1.8版本时升级为??GA??。作为kubeadm安装方式的默认选项，足见其重要程度。相对于其他访问控制方式，新的RBAC具有如下优势。

◎ 对集群中的资源和非资源权限均有完整的覆盖。
◎ 整个RBAC完全由几个API对象完成，同其他API对象一样，可以用kubectl或API进行操作。
◎ 可以在运行时进行调整，无须重新启动API Server。要使用RBAC授权模式，需要在API Server的启动参数中加上??--authorization-mode=RBAC??。

=Example,RBAC --< 其他选项> --< 其他选项>

下面对RBAC的原理和用法进行说明。
2. API 对象RBAC API 声明了四种 Kubernetes 对象：??Role???、??ClusterRole???、??RoleBinding??? 和 ??ClusterRoleBinding??。你可以像使用其他 Kubernetes 对象一样，通过类似 kubectl 这类工具描述对象, 或修补对象。
2.1 角色（Role）
一个角色就是一组权限的集合，这里的权限都是许可形式的，不存在拒绝的规则。在一个命名空间中，可以用角色来定义一个角色，如果是集群级别的，就需要使用ClusterRole了。角色只能对命名空间内的资源进行授权，在下面例子中定义的角色具备读取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"]

rules中的参数说明如下。
◎ ???apiGroups???：支持的API组列表，例如“??apiVersion:batch/v1???”“??apiVersion: extensions:v1beta1???”“??apiVersion: apps/v1beta1???”等，
详细的API组说明参见第9章的说明。
◎ ???resources???：支持的资源对象列表，例如pods、deployments、
jobs等。
◎ ???verbs??：对资源对象的操作方法列表，例如get、watch、list、delete、replace、patch等，详细的操作方法说明参见第9章的说明。
2.2 集群角色（ClusterRole）
集群角色除了具有和角色一致的命名空间内资源的管理能力，因其集群级别的范围，还可以用于以下特殊元素的授权。
◎ 集群范围的资源，例如Node。
◎ 非资源型的路径，例如“/healthz”。
◎ 包含全部命名空间的资源，例如pods（用于kubectl get pods –
all-namespaces这样的操作授权）。
下面的集群角色可以让用户有权访问任意一个或所有命名空间的secrets（视其绑定方式而定）：

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

2.3 角色绑定（RoleBinding）和集群角色绑定（ClusterRoleBinding）
角色绑定或集群角色绑定用来把一个角色绑定到一个目标上，绑定目标可以是??User???（用户）、??Group???（组）或者??Service Account???。使用??RoleBinding???为某个命名空间授权，使用??ClusterRoleBinding???为集群范围内授权。
RoleBinding可以引用Role进行授权。下面的例子中的RoleBinding将在default命名空间中把pod-reader角色授予用户jane，这一操作可以让jane读取default命名空间中的Pod：

apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定允许 "jane" 读取 "default" 名字空间中的 Pods
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 的名称匹配

??RoleBinding???也可以引用??ClusterRole???，对属于同一命名空间内ClusterRole定义的资源主体进行授权。一种常见的做法是集群管理员为集群范围预先定义好一组ClusterRole，然后在多个命名空间中重复使用这些ClusterRole。例如，在下面的例子中，虽然??secret-reader??是一个集群角色，但是因为使用了RoleBinding，所以dave只能读取development命名空间中的secret：

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

集群角色绑定中的角色只能是集群角色，用于进行集群级别或者对所有命名空间都生效的授权。下面的例子允许manager组的用户读取任意Namespace中的secret：

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

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

针对不同角色的绑定是完全不一样的绑定。要求通过删除/重建绑定来更改 roleRef,
这样可以确保要赋予绑定的所有主体会被授予新的角色（而不是在允许修改 roleRef的情况下导致所有现有主体胃镜验证即被授予新角色对应的权限）。
将 roleRef 设置为不可以改变，这使得可以为用户授予对现有绑定对象的 update 权限，这样可以让他们管理主体列表，同时不能更改被授予这些主体的角色。

命令 ??kubectl auth reconcile?? 可以创建或者更新包含 RBAC 对象的清单文件，并且在必要的情况下删除和重新创建绑定对象，以改变所引用的角色。更多相关信息请参照命令用法和示例
3. 对资源的引用多数资源可以用其名称的字符串来表达，也就是Endpoint中的URL相对路径，例如pods。然而，某些Kubernetes API包含下级资源，例如Pod的日志（logs）。Pod日志的Endpoint是??GET/api/v1/namespaces/namespace/pods/name/log???。
在这个例子中，Pod是一个命名空间内的资源，log就是一个下级资源。要在一个RBAC角色中体现，就需要用斜线“/”来分隔资源和下级资源。若想授权让某个主体同时能够读取Pod和Pod log，则可以配置resources为一个数组：

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

可想而知，resourceName这种用法对list、watch、create或deletecollection操作是无效的，这是因为必须要通过URL进行鉴权，而资源名称在list、watch、create deletecollection请求中只是请求Body数据的一部分。
4. 聚合的 ClusterRole你可以将若干 ClusterRole 聚合（Aggregate）起来，形成一个复合的 ClusterRole。某个控制器作为集群控制面的一部分会监视带有 aggregationRule 的 ClusterRole 对象集合。??aggregationRule?? 为控制器定义一个标签选择算符供后者匹配应该组合到当前 ClusterRole 的 roles 字段中的 ClusterRole 对象。
下面是一个聚合 ClusterRole 的示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring
aggregationRule:
clusterRoleSelectors:
- matchLabels:
rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # 控制面自动填充这里的规则

如果你创建一个与某现有聚合 ClusterRole 的标签选择算符匹配的 ClusterRole，这一变化会触发新的规则被添加到聚合 ClusterRole 的操作。下面的例子中，通过创建一个标签同样为 ??rbac.example.com/aggregate-to-monitoring: true?? 的 ClusterRole，新的规则可被添加到 “monitoring” ClusterRole 中。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring-endpoints
labels:
rbac.example.com/aggregate-to-monitoring: "true"
# 当你创建 "monitoring-endpoints" ClusterRole 时，
# 下面的规则会被添加到 "monitoring" ClusterRole 中
rules:
- apiGroups: [""]
resources: ["services", "endpoints", "pods"]
verbs: ["get", "list", "watch"]

默认的面向用户的角色使用 ClusterRole 聚合。这使得作为集群管理员的你可以为扩展默认规则，包括为定制资源设置规则，比如通过 ??CustomResourceDefinitions??? 或聚合 API 服务器提供的定制资源。
例如，下面的 ClusterRoles 让默认角色 “admin” 和 “edit” 拥有管理自定义资源 “CronTabs” 的权限， “view” 角色对 CronTab 资源拥有读操作权限。你可以假定 CronTab 对象在 API 服务器所看到的 URL 中被命名为 “crontabs”。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: aggregate-cron-tabs-edit
labels:
# 添加以下权限到默认角色 "admin" 和 "edit" 中
rbac.authorization.k8s.io/aggregate-to-admin: "true"
rbac.authorization.k8s.io/aggregate-to-edit: "true"
rules:
- apiGroups: ["stable.example.com"]
resources: ["crontabs"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: aggregate-cron-tabs-view
labels:
# 添加以下权限到 "view" 默认角色中
rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: ["stable.example.com"]
resources: ["crontabs"]
verbs: ["get", "list", "watch"]

5. Role 示例以下示例均为从 Role 或 CLusterRole 对象中截取出来，我们仅展示其 rules 部分。
允许读取在核心 API 组下的 “Pods”：

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

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

rules:
- apiGroups: ["extensions", "apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

允许读取核心 API 组中的 “pods” 和读/写 “batch” 或 “extensions” API 组中的 “jobs”：

rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
- apiGroups: ["batch", "extensions"]
resources: ["jobs"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

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

rules:
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["my-config"]
verbs: ["get"]

【kubernetes RBAC相遇--介绍常规用法集群默认】允许读取在核心组中的 “nodes” 资源（因为 Node 是集群作用域的，所以需要 ClusterRole 绑定到 ClusterRoleBinding 才生效）：

rules:
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list", "watch"]

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

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

6. 对主体的引用??RoleBinding??? 或者 ??ClusterRoleBinding?? 可绑定角色到某 *主体（Subject）*上。主体可以是组，用户或者服务账号。
Kubernetes 用字符串来表示用户名。用户名可以是普通的用户名，像 “alice”；或者是邮件风格的名称，如 “bob@example.com”，或者是以字符串形式表达的数字 ID。你作为 Kubernetes 管理员负责配置身份认证模块以便后者能够生成你所期望的格式的用户名。

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

7. RoleBinding 示例下面示例是 RoleBinding 中的片段，仅展示其 subjects 的部分。
对于名称为 alice@example.com 的用户：

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

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

subjects:
- kind: Group
name: "frontend-admins"

对于 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: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

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

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

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

9. 面向用户的角色一些默认的 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"

10. 核心组件角色

默认 ClusterRole	默认 ClusterRoleBinding	描述
cluster-admin	system:masters 组	允许超级用户在平台上的任何资源上执行所有操作。当在 ClusterRoleBinding 中使用时，可以授权对集群中以及所有名字空间中的全部资源进行完全控制。当在 RoleBinding 中使用时，可以授权控制 RoleBinding 所在名字空间中的所有资源，包括名字空间本身。
admin	无	允许管理员访问权限，旨在使用 RoleBinding 在名字空间内执行授权。如果在 RoleBinding 中使用，则可授予对名字空间中的大多数资源的读/写权限，包括创建角色和角色绑定的能力。但是它不允许对资源配额或者名字空间本身进行写操作。
edit	无	允许对名字空间的大多数对象进行读/写操作。它不允许查看或者修改角色或者角色绑定。不过，此角色可以访问 Secret，以名字空间中任何 ServiceAccount 的身份运行 Pods，所以可以用来了解名字空间内所有服务账号的 API 访问级别。
view	无
system:kube-scheduler	system:kube-scheduler user	允许访问 scheduler 组件所需要的资源。
system:volume-scheduler	system:kube-scheduler user	允许访问 kube-scheduler 组件所需要的卷资源。
system:kube-controller-manager	system:kube-controller-manager user	允许访问控制器管理器组件所需要的资源。各个控制回路所需要的权限在控制器角色详述。
system:node	无	允许访问 kubelet 所需要的资源，包括对所有 Secret 的读操作和对所有 Pod 状态对象的写操作。
你应该使用 Node 鉴权组件和 NodeRestriction 准入插件而不是 system:node 角色。同时基于 kubelet 上调度执行的 Pod 来授权 kubelet 对 API 的访问。 system:node 角色的意义仅是为了与从 v1.8 之前版本升级而来的集群兼容。

system:node-proxier	system:kube-proxy user	允许访问 kube-proxy 组件所需要的资源

11. 其他组件角色

默认 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	无	允许访问大部分动态卷驱动所需要的资源

12. 内置控制器的角色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

13. 对角色绑定创建或更新的限制例如，下面的 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"]
resources: ["rolebindings"]
verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["clusterroles"]
verbs: ["bind"]
# 忽略 resourceNames 意味着允许绑定任何 ClusterRole
resourceNames: ["admin","edit","view"]

当启动引导第一个角色和角色绑定时，需要为初始用户授予他们尚未拥有的权限。对初始角色和角色绑定进行初始化时需要：
使用用户组为 system:masters 的凭据，该用户组由默认绑定关联到 cluster-admin 这个超级用户角色。
如果你的 API 服务器启动时启用了不安全端口（使用 --insecure-port）, 你也可以通过该端口调用 API