Kubernetes RBAC角色权限控制

分享到:

Kubernetes RBAC角色权限控制

[TOC]

Kubernetes RBAC角色权限控制

RBAC——基于角色的访问控制 Kubernetes RBAC角色权限控制

什么是 Kubernetes RBAC

在Kubernetes中,授权有ABAC(基于属性的访问控制)、RBAC(基于角色的访问控制)、Webhook、Node、AlwaysDeny(一直拒绝)和AlwaysAllow(一直允许)这6种模式。从1.6版本起,Kubernetes 默认启用RBAC访问控制策略(beta版本)。从1.8开始,RBAC已作为稳定的功能。通过设置–authorization-mode=RBAC,启用RABC。在RABC API中,通过如下的步骤进行授权:1)定义角色:在定义角色时会指定此角色对于资源的访问控制的规则;2)绑定角色:将主体与角色进行绑定,对用户进行访问授权。

基于角色的访问控制(Role-Based Access Control, 即 "RBAC"):使用 “rbac.authorization.k8s.io” API Group 实现授权决策,允许管理员通过 Kubernetes API 动态配置策略。

RBAC 从 Kubernetes v1.6 处于beta版本,从 v1.8 开始,RBAC已作为 稳定的功能。启用 RBAC,请使用 --authorization-mode=RBAC 启动 API Server。

三个RBAC最基本的概念

  • Role: 角色,它定义了一组规则,定义了一组对Kubernetes API对象的操作权限
  • Subject: 被作用者,既可以是"人",也可以是机器,当然也可以是我们Kubernetes中定义的用户(ServiceAccount主要负责kubernetes内置用户)
  • RoleBinding: 定义了"被作用者"和"角色"的绑定关系

在Kubernetes中所有的API对象都保存在ETCD里,可是,对这些API对象的操作,却一定是通过访问kube-apiserver实现的。我们需要APIServer来帮助我们授权工作,而在Kubernetes项目中,负责完成授权(Authorization)的工作机制就是RBAC: 基于角色的访问控制 (Role-Based Access Control)

RBAC是基于角色的访问控制 (Role-Based Access Control) 在RBAC中,权限与角色相关联。Kubernetes 基于角色的访问控制使用rbac.authorization.k8s.io API组来实现权限控制,RBAC允许管理员通过Kubernetes API动态的配置权限策略。如果需要开启RBAC授权需要在apiserver组件中指定--authorization-mode=Node,RBAC

ClusterRole 与 Role

在RBAC API中,角色包含代表权限集合的规则。在这里,权限只有被授予,而没有被拒绝的设置。在Kubernetes中有两类角色,即普通角色和集群角色。可以通过Role定义在一个命名空间中的角色,或者可以使用ClusterRole定义集群范围的角色。一个角色只能被用来授予访问单一命令空间中的资源。下面是在“default”命令空间中定义了一个名为“pod-reader”的角色,此角色能够对在“default”命名空间中访问Pod.

Role(角色)

是一系列权限的集合,例如一个角色可以包含读取 Pod 的权限和列出 Pod 的权限。Role 只能用来给某个特定 namespace 中的资源作鉴权。对 namespace 、集群级资源 和 非资源类的 API(如 /healthz)使用 ClusterRole

1kind: Role
2apiVersion: rbac.authorization.k8s.io/v1beta1
3metadata:
4  namespace: default
5  name: pod-reader
6rules:
7- apiGroups: [""] # 空字符串""表明使用 core API group
8  resources: ["pods"]
9  verbs: ["get", "watch", "list"]

上面的例子描述了 ”default” 命名空间中的一个 Role 对象的定义,用于授予对 pod 的读访问权限。

ClusterRole

对象可以授予与 Role 对象相同的权限,但由于它们属于集群范围对象,也可以使用它们授予对以下几种资源的访问权限:

  • 集群范围资源(例如节点,即 node)
  • 非资源类型 endpoint(例如 /healthz)
  • 跨所有命名空间的命名空间范围资源(例如 pod,需要运行命令 kubectl get pods --all-namespaces 来查询集群中所有的 pod)
1kind: ClusterRole
2apiVersion: rbac.authorization.k8s.io/v1beta1
3metadata:
4  # ClusterRole 是集群范围对象,所以不需要定义 "namespace" 字段
5  name: secret-reader
6rules:
7- apiGroups: [""]
8  resources: ["secrets"] #明确资源类型
9  verbs: ["get", "watch", "list"]

上面例子中的 ClusterRole 定义可用于授予用户对某一特定命名空间,或者所有命名空间中的 secret(取决于其绑定方式)的读访问权限

Kubernetes还提供了四个预先定义好的ClusterRole来提供用户直接使用

  • cluster-admin
  • admin
  • edit
  • view

其中cluster-admin角色,对应的是整个Kubernetes项目中最高权限(verbs=*)

我们可以通过下面的命令查看clusterrole的权限

1[root@node1 ~]# kubectl describe clusterrole cluster-admin -n kube-system
2Name:         cluster-admin
3Labels:       kubernetes.io/bootstrapping=rbac-defaults
4Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
5PolicyRule:
6  Resources  Non-Resource URLs  Resource Names  Verbs
7  ---------  -----------------  --------------  -----
8  *.*        []                 []              [*]
9             [*]                []              [*]

ClusterRoleBinding 与 RoleBinding

RoleBinding:

把 Role 或 ClusterRole 中定义的各种权限映射到 User,Service Account 或者 Group,从而让这些用户继承角色在 namespace 中的权限。

RoleBinding 可以引用在同一命名空间内定义的 Role 对象。

 1# 以下角色绑定定义将允许用户 "jane" 从 "default" 命名空间中读取 pod。
 2kind: RoleBinding
 3apiVersion: rbac.authorization.k8s.io/v1beta1
 4metadata:
 5  name: read-pods
 6  namespace: default
 7subjects:
 8- kind: User
 9  name: jane
10  apiGroup: rbac.authorization.k8s.io
11roleRef:
12  kind: Role
13  name: pod-reader
14  apiGroup: rbac.authorization.k8s.io

RoleBinding 对象也可以引用一个 ClusterRole 对象用于在 RoleBinding 所在的命名空间内授予用户对所引用的 ClusterRole 中定义的命名空间资源的访问权限。 这一点允许管理员在整个集群范围内首先定义一组通用的角色,然后再在不同的命名空间中复用这些角色。

例如,尽管下面示例中的 RoleBinding 引用的是一个 ClusterRole 对象,但是用户 ”dave” (即角色绑定主体)还是只能读取 ”development” 命名空间中的 secret(即 RoleBinding 所在的命名空间)。

 1kind: RoleBinding
 2apiVersion: rbac.authorization.k8s.io/v1beta1
 3metadata:
 4  name: read-secrets
 5  namespace: development # 这里表明仅授权读取 "development" 命名空间中的资源。
 6subjects:
 7- kind: User
 8  name: dave
 9  apiGroup: rbac.authorization.k8s.io
10roleRef:
11  kind: ClusterRole
12  name: secret-reader
13  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding:

让用户继承 ClusterRole 在整个集群中的权限。

使用 ClusterRoleBinding 在集群级别和所有命名空间中授予权限。下面示例中所定义的 ClusterRoleBinding 允许在用户组 ”manager” 中的任何用户都可以读取 集群中任何命名空间中的 secret。

 1kind: ClusterRoleBinding
 2apiVersion: rbac.authorization.k8s.io/v1beta1
 3metadata:
 4  name: read-secrets-global
 5subjects:
 6- kind: Group
 7  name: manager
 8  apiGroup: rbac.authorization.k8s.io
 9roleRef:
10  kind: ClusterRole
11  name: secret-reader
12  apiGroup: rbac.authorization.k8s.io

ClusterRole 聚合

从 v1.9 开始,在 ClusterRole 中可以通过 aggregationRule 来与其他 ClusterRole 聚合使用:

 1kind: ClusterRole
 2apiVersion: rbac.authorization.k8s.io/v1
 3metadata:
 4  name: monitoring
 5aggregationRule:
 6  clusterRoleSelectors:
 7  - matchLabels:
 8      rbac.example.com/aggregate-to-monitoring: "true"
 9rules: [] # Rules are automatically filled in by the controller manager.
10---
11kind: ClusterRole
12apiVersion: rbac.authorization.k8s.io/v1
13metadata:
14  name: monitoring-endpoints
15  labels:
16    rbac.example.com/aggregate-to-monitoring: "true"
17# These rules will be added to the "monitoring" role.
18rules:
19- apiGroups: [""]
20  resources: ["services", "endpoints", "pods"]
21  verbs: ["get", "list", "watch"]

ServiceAccount

ServiceAccount主要负责kubernetes内置用户,下面简单定义一个ServiceAccount

1apiVersion: v1
2kind: ServiceAccount
3metadata:
4 namespace: mynamespace
5 name: example-sa

我们定义了一个serverAccount对象,只需要name以及namespace最基础字段就可以。然后通过编写rolebinding的yaml文件,来为这个serviceAccount分配权限

 1kind: RoleBinding
 2apiVersion: rbac.authorization.k8s.io/v1
 3metadata:
 4 name: example-rolebinding
 5 namespace: mynamespace
 6subjects:
 7- kind: ServiceAccount
 8 name: example-sa
 9 namespace: mynamespace
10roleRef:
11 kind: Role
12 name: example-role
13 apiGroup: rbac.authorization.k8s.io

在Rolebinding对象里,subject字段的类型(kind),不在是一个User,而是一个名叫example-sa的ServerAccount。而roleRef引用的Role对象,依然名叫example-role。也就是我们上面定义的

User && Group

Kubernetes除了有用户(User),还拥有用户组(Group)概念,如果我们Kubernetes配置了外部认证服务的话,这个用户组的概念就由外部认证服务提供 一个ServiceAccount在Kubernetes对应的用户的名字是

1system:serviceaccount:<ServiceAccount名字>

而对应的用户组则是

1system:serviceaccounts:<Namespace名字>

比如,我们可以在RoleBinding中定义如下subjects

1subjects:
2- kind: Group
3 name: system:serviceaccounts:mynamespace
4 apiGroup: rbac.authorization.k8s.io

这就意味着role的规则权限,作用于mynamespace里的所有ServiceAccount,这就用到了用户组的概念

1subjects:
2- kind: Group
3 name: system:serviceaccounts
4 apiGroup: rbac.authorization.k8s.io

这个role的规则权限,则作用于整个系统里ServiceAccount

在Kubernetes中已经内置了很多歌为系统保留的ClusterRole,它们的名字都以system:开头,可以使用kubectl get clusterroles查找到

 1[root@node1 ~]# kubectl get clusterroles
 2NAME                                                                   AGE
 3admin                                                                  3d21h
 4cluster-admin                                                          3d21h
 5custom-metrics-resource-reader                                         3h22m
 6custom-metrics-server-resources                                        3h22m
 7edit                                                                   3d21h
 8flannel                                                                3d21h
 9prometheus                                                             3h23m
10system:aggregate-to-admin                                              3d21h
11system:aggregate-to-edit                                               3d21h
12system:aggregate-to-view                                               3d21h
13system:auth-delegator                                                  3d21h
14system:basic-user                                                      3d21h
15system:certificates.k8s.io:certificatesigningrequests:nodeclient       3d21h
16system:certificates.k8s.io:certificatesigningrequests:selfnodeclient   3d21h
17system:controller:attachdetach-controller                              3d21h
18system:controller:certificate-controller                               3d21h
19system:controller:clusterrole-aggregation-controller                   3d21h
20system:controller:cronjob-controller                                   3d21h
21system:controller:daemon-set-controller                                3d21h
22system:controller:deployment-controller                                3d21h
23system:controller:disruption-controller                                3d21h
24system:controller:endpoint-controller                                  3d21h
25system:controller:expand-controller                                    3d21h
26system:controller:generic-garbage-collector                            3d21h
27system:controller:horizontal-pod-autoscaler                            3d21h
28system:controller:job-controller                                       3d21h
29system:controller:namespace-controller                                 3d21h
30system:controller:node-controller                                      3d21h
31system:controller:persistent-volume-binder                             3d21h
32system:controller:pod-garbage-collector                                3d21h
33system:controller:pv-protection-controller                             3d21h
34system:controller:pvc-protection-controller                            3d21h
35system:controller:replicaset-controller                                3d21h
36system:controller:replication-controller                               3d21h
37system:controller:resourcequota-controller                             3d21h
38system:controller:route-controller                                     3d21h
39system:controller:service-account-controller                           3d21h
40system:controller:service-controller                                   3d21h
41system:controller:statefulset-controller                               3d21h
42system:controller:ttl-controller                                       3d21h
43system:coredns                                                         3d21h
44system:csi-external-attacher                                           3d21h
45system:csi-external-provisioner                                        3d21h
46system:discovery                                                       3d21h
47system:heapster                                                        3d21h
48system:kube-aggregator                                                 3d21h
49system:kube-controller-manager                                         3d21h
50system:kube-dns                                                        3d21h
51system:kube-scheduler                                                  3d21h
52system:kubelet-api-admin                                               3d21h
53system:metrics-server                                                  3h25m
54system:node                                                            3d21h
55system:node-bootstrapper                                               3d21h
56system:node-problem-detector                                           3d21h
57system:node-proxier                                                    3d21h
58system:persistent-volume-provisioner                                   3d21h
59system:public-info-viewer                                              3d21h
60system:volume-scheduler                                                3d21h
61view                                                                   3d21h
62

现在我们可以理解,所谓的角色(Role),其实就是一组规则权限列表,而我们分配这些权限的方式,就是通过创建RoleBinding对象,将被用者(subject)和权限列表绑定。

而对应的ClusterRole和ClusterRoleBinding,则是Kubernetes集群级别的Role和RoleBinding,它们不受namespace限制

对资源的引用

RBAC API对象

Kubernetes有一个很基本的特性就是它的所有资源都是模型化的API对象,允许执行CRUD(Create、Read、Update、Delete)操作。资源如下

主要的资源包括:

  • Pods
  • Nodes
  • Services
  • Deployment
  • Replicasets
  • Statefulsets
  • Namespace
  • Persistents
  • Secrets
  • ConfigMaps
  • ...

资源对象可能存在的操作有如下:

  • create
  • get
  • delete
  • list
  • update
  • edit
  • watch
  • exec

这些资源和API Group进行关联,比如Pods属于Core API Group,而Deployment属于apps API Group,要在kubernetes中进行RBAC授权

大多数资源由代表其名字的字符串表示,例如 ”pods”,就像它们出现在相关API endpoint 的URL中一样。然而,有一些Kubernetes API还 包含了”子资源”,比如 pod 的 logs。在Kubernetes中,pod logs endpoint的URL格式为:

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

在这种情况下,”pods” 是命名空间资源,而 ”log” 是 pods 的子资源。为了在 RBAC Role 中表示出这一点,我们需要使用斜线来划分资源与子资源。 如果需要 Role 绑定主体读取 pods 以及 pods log(如果不显示指定子资源,那么子资源是没有权限访问的),需要定义以下 Role

1kind: Role
2apiVersion: rbac.authorization.k8s.io/v1beta1
3metadata:
4  namespace: default
5  name: pod-and-pod-logs-reader
6rules:
7- apiGroups: [""]
8  resources: ["pods", "pods/log"]
9  verbs: ["get", "list"]

上面的例子显示,“pod-and-pod-logs-reader”角色能够对“pods”和“pods/log”进行访问

通过 resourceNames 列表,Role可以针对不同种类的请求根据资源名引用资源实例。当指定了 resourceNames 列表时,不同动作种类的请求的权限, 如使用 ”get”、”delete”、”update” 以及 ”patch” 等动词的请求,将被限定到资源列表中所包含的资源实例上。 例如,如果需要限定一个角色绑定主体只能 ”get” 或者 ”update” 一个名为 “my-configmap” 的 configmap 时,可以定义以下角色:

 1kind: Role
 2apiVersion: rbac.authorization.k8s.io/v1beta1
 3metadata:
 4  namespace: default
 5  name: configmap-updater
 6rules:
 7- apiGroups: [""]
 8  resources: ["configmap"]
 9  resourceNames: ["my-configmap"]
10  verbs: ["update", "get"]

值得注意的是,如果设置了resourceNames,则请求所使用的动词不能是list、watch、create或者deletecollection。 由于资源名不会出现在create、list、watch和deletecollection等API请求的URL中,所以这些请求动词不会被设置了resourceNames 的规则所允许,因为规则中的resourceNames部分不会匹配这些请求。

角色定义的例子

使用 kubectl api-resources 查看所有 kubernetes 资源对象所属的 apiGroups

 1[root@node1 ~]# kubectl api-resources
 2NAME                              SHORTNAMES   APIGROUP                       NAMESPACED   KIND
 3bindings                                                                      true         Binding
 4componentstatuses                 cs                                          false        ComponentStatus
 5configmaps                        cm                                          true         ConfigMap
 6endpoints                         ep                                          true         Endpoints
 7events                            ev                                          true         Event
 8limitranges                       limits                                      true         LimitRange
 9namespaces                        ns                                          false        Namespace
10nodes                             no                                          false        Node
11persistentvolumeclaims            pvc                                         true         PersistentVolumeClaim
12persistentvolumes                 pv                                          false        PersistentVolume
13pods                              po                                          true         Pod
14podtemplates                                                                  true         PodTemplate
15replicationcontrollers            rc                                          true         ReplicationController
16resourcequotas                    quota                                       true         ResourceQuota
17secrets                                                                       true         Secret
18serviceaccounts                   sa                                          true         ServiceAccount
19services                          svc                                         true         Service
20mutatingwebhookconfigurations                  admissionregistration.k8s.io   false        MutatingWebhookConfiguration
21validatingwebhookconfigurations                admissionregistration.k8s.io   false        ValidatingWebhookConfiguration
22customresourcedefinitions         crd,crds     apiextensions.k8s.io           false        CustomResourceDefinition
23apiservices                                    apiregistration.k8s.io         false        APIService
24controllerrevisions                            apps                           true         ControllerRevision
25daemonsets                        ds           apps                           true         DaemonSet
26deployments                       deploy       apps                           true         Deployment
27replicasets                       rs           apps                           true         ReplicaSet
28statefulsets                      sts          apps                           true         StatefulSet
29tokenreviews                                   authentication.k8s.io          false        TokenReview
30localsubjectaccessreviews                      authorization.k8s.io           true         LocalSubjectAccessReview
31selfsubjectaccessreviews                       authorization.k8s.io           false        SelfSubjectAccessReview
32selfsubjectrulesreviews                        authorization.k8s.io           false        SelfSubjectRulesReview
33subjectaccessreviews                           authorization.k8s.io           false        SubjectAccessReview
34horizontalpodautoscalers          hpa          autoscaling                    true         HorizontalPodAutoscaler
35cronjobs                          cj           batch                          true         CronJob
36jobs                                           batch                          true         Job
37certificatesigningrequests        csr          certificates.k8s.io            false        CertificateSigningRequest
38leases                                         coordination.k8s.io            true         Lease
39events                            ev           events.k8s.io                  true         Event
40ingresses                         ing          extensions                     true         Ingress
41nodes                                          metrics.k8s.io                 false        NodeMetrics
42pods                                           metrics.k8s.io                 true         PodMetrics
43ingresses                         ing          networking.k8s.io              true         Ingress
44networkpolicies                   netpol       networking.k8s.io              true         NetworkPolicy
45runtimeclasses                                 node.k8s.io                    false        RuntimeClass
46poddisruptionbudgets              pdb          policy                         true         PodDisruptionBudget
47podsecuritypolicies               psp          policy                         false        PodSecurityPolicy
48clusterrolebindings                            rbac.authorization.k8s.io      false        ClusterRoleBinding
49clusterroles                                   rbac.authorization.k8s.io      false        ClusterRole
50rolebindings                                   rbac.authorization.k8s.io      true         RoleBinding
51roles                                          rbac.authorization.k8s.io      true         Role
52priorityclasses                   pc           scheduling.k8s.io              false        PriorityClass
53csidrivers                                     storage.k8s.io                 false        CSIDriver
54csinodes                                       storage.k8s.io                 false        CSINode
55storageclasses                    sc           storage.k8s.io                 false        StorageClass
56volumeattachments                              storage.k8s.io                 false        VolumeAttachment
57

如果 apiGroups: [""] 则表示 core API Group。

在以下示例中,我们仅截取展示了rules部分的定义。

允许读取 core API Group 中定义的资源 ”pods”:

1rules:
2- apiGroups: [""]
3  resources: ["pods"]
4  verbs: ["get", "list", "watch"]

允许读写在 ”extensions” 和 ”apps” API Group 中定义的 ”deployments”:

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

允许读取”pods”以及读写”jobs”:

1rules:
2- apiGroups: [""]
3  resources: ["pods"]
4  verbs: ["get", "list", "watch"]
5- apiGroups: ["batch", "extensions"]
6  resources: ["jobs"]
7  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

允许读取一个名为”my-config”的ConfigMap实例(需要将其通过RoleBinding绑定从而限制针对某一个命名空间中定义的一个ConfigMap实例的访问):

1rules:
2- apiGroups: [""]
3  resources: ["configmaps"]
4  resourceNames: ["my-config"]
5  verbs: ["get"]

允许读取core API Group中的”nodes”资源(由于Node是集群级别资源,所以此ClusterRole定义需要与一个ClusterRoleBinding绑定才能有效):

1rules:
2- apiGroups: [""]
3  resources: ["nodes"]
4  verbs: ["get", "list", "watch"]

允许对非资源endpoint “/healthz”及其所有子路径的”GET”和”POST”请求(此ClusterRole定义需要与一个ClusterRoleBinding绑定才能有效):

1rules:
2- nonResourceURLs: ["/healthz", "/healthz/*"] # 在非资源URL中,'*'代表后缀通配符
3  verbs: ["get", "post"]

绑定用户能查看所有 namespace

 1apiVersion: rbac.authorization.k8s.io/v1
 2kind: ClusterRole
 3metadata:
 4  # 鉴于ClusterRole是集群范围对象,所以这里不需要定 义"namespace"字段
 5  name: view-namespace-clusterrole
 6rules:
 7- apiGroups:
 8  - ""
 9  resources:
10  - namespaces
11  - namespaces/status
12  verbs:
13  - get
14  - list
15  - watch

定义 develop-role 用户对 default 命名空间详细权限

  1apiVersion: rbac.authorization.k8s.io/v1
  2kind: Role
  3metadata:
  4  name: develop-role
  5  namespace: default
  6rules:
  7- apiGroups:
  8  - ""
  9  resources:
 10  - endpoints
 11  - serviceaccounts
 12  - configmaps
 13  - persistentvolumeclaims
 14  - persistentvolumes
 15  - services
 16  - replicationcontrollers
 17  - replicationcontrollers/scale
 18  verbs:
 19  - get
 20  - list
 21  - watch
 22- apiGroups:
 23  - ""
 24  resources:
 25  - pods
 26  - pods/log
 27  - pods/status
 28  - pods/exec
 29  verbs:
 30  - create
 31  - delete
 32  - deletecollection
 33  - patch
 34  - update
 35  - get
 36  - list
 37  - watch
 38- apiGroups:
 39  - ""
 40  resources:
 41  - bindings
 42  - events
 43  - limitranges
 44  - namespaces/status
 45  - replicationcontrollers/status
 46  - resourcequotas
 47  - resourcequotas/status
 48  verbs:
 49  - get
 50  - list
 51  - watch
 52- apiGroups:
 53  - ""
 54  resources:
 55  - namespaces
 56  verbs:
 57  - get
 58  - list
 59  - watch
 60- apiGroups:
 61  - apps
 62  resources:
 63  - daemonsets
 64  - statefulsets
 65  verbs:
 66  - get
 67  - list
 68  - watch
 69- apiGroups:
 70  - apps
 71  resources:
 72  - deployments
 73  - deployments/scale
 74  - replicasets
 75  - replicasets/scale
 76  verbs:
 77  - get
 78  - list
 79  - watch
 80  - update
 81- apiGroups:
 82  - autoscaling
 83  resources:
 84  - horizontalpodautoscalers
 85  verbs:
 86  - get
 87  - list
 88  - watch
 89- apiGroups:
 90  - batch
 91  resources:
 92  - cronjobs
 93  - jobs
 94  verbs:
 95  - get
 96  - list
 97  - watch
 98- apiGroups:
 99  - extensions
100  resources:
101  - daemonsets
102  - statefulsets
103  - ingresses
104  - networkpolicies
105  verbs:
106  - get
107  - list
108  - watch
109- apiGroups:
110  - extensions
111  resources:
112  - deployments
113  - deployments/scale
114  - replicasets
115  - replicasets/scale
116  - replicationcontrollers/scale
117  verbs:
118  - get
119  - list
120  - watch
121  - update
122- apiGroups:
123  - policy
124  resources:
125  - poddisruptionbudgets
126  verbs:
127  - get
128  - list
129  - watch
130- apiGroups:
131  - networking.k8s.io
132  resources:
133  - networkpolicies
134  verbs:
135  - get
136  - list
137  - watch

对角色绑定主体(Subject)的引用

RoleBinding或者ClusterRoleBinding将角色绑定到角色绑定主体(Subject)。 角色绑定主体可以是用户组(Group)、用户(User)或者服务账户(Service Accounts)。

用户由字符串表示。可以是纯粹的用户名,例如”alice”、电子邮件风格的名字,如 “bob@example.com” 或者是用字符串表示的数字id。由Kubernetes管理员配置认证模块 以产生所需格式的用户名。对于用户名,RBAC授权系统不要求任何特定的格式。然而,前缀system:是 为Kubernetes系统使用而保留的,所以管理员应该确保用户名不会意外地包含这个前缀。

Kubernetes中的用户组信息由授权模块提供。用户组与用户一样由字符串表示。Kubernetes对用户组 字符串没有格式要求,但前缀system:同样是被系统保留的。

服务账户拥有包含 system:serviceaccount:前缀的用户名,并属于拥有system:serviceaccounts:前缀的用户组。

角色绑定的一些例子

以下示例中,仅截取展示了RoleBinding的subjects字段。

一个名为”alice@example.com”的用户:

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

一个名为”frontend-admins”的用户组:

1subjects:
2- kind: Group
3  name: "frontend-admins"
4  apiGroup: rbac.authorization.k8s.io

kube-system命名空间中的默认服务账户:

1subjects:
2- kind: ServiceAccount
3  name: default
4  namespace: kube-system

名为”qa”命名空间中的所有服务账户:

1subjects:
2- kind: Group
3  name: system:serviceaccounts:qa
4  apiGroup: rbac.authorization.k8s.io

在集群中的所有服务账户:

1subjects:
2- kind: Group
3  name: system:serviceaccounts
4  apiGroup: rbac.authorization.k8s.io

所有认证过的用户(version 1.5+):

1subjects:
2- kind: Group
3  name: system:authenticated
4  apiGroup: rbac.authorization.k8s.io

所有未认证的用户(version 1.5+):

1subjects:
2- kind: Group
3  name: system:unauthenticated
4  apiGroup: rbac.authorization.k8s.io

所有用户(version 1.5+):

1subjects:
2- kind: Group
3  name: system:authenticated
4  apiGroup: rbac.authorization.k8s.io
5- kind: Group
6  name: system:unauthenticated
7  apiGroup: rbac.authorization.k8s.io

默认角色与默认角色绑定

API Server会创建一组默认的ClusterRole和ClusterRoleBinding对象。 这些默认对象中有许多包含system:前缀,表明这些资源由Kubernetes基础组件”拥有”。 对这些资源的修改可能导致非功能性集群(non-functional cluster)。一个例子是system:node ClusterRole对象。 这个角色定义了kubelets的权限。如果这个角色被修改,可能会导致kubelets无法正常工作。

所有默认的ClusterRole和ClusterRoleBinding对象都会被标记为kubernetes.io/bootstrapping=rbac-defaults

自动更新

每次启动时,API Server都会更新默认ClusterRole所缺乏的各种权限,并更新默认ClusterRoleBinding所缺乏的各个角色绑定主体。 这种自动更新机制允许集群修复一些意外的修改。由于权限和角色绑定主体在新的Kubernetes释出版本中可能变化,这也能够保证角色和角色 绑定始终保持是最新的。

如果需要禁用自动更新,请将默认ClusterRole以及ClusterRoleBinding的rbac.authorization.kubernetes.io/autoupdate 设置成为false。 请注意,缺乏默认权限和角色绑定主体可能会导致非功能性集群问题。

自Kubernetes 1.6+起,当集群RBAC授权器(RBAC Authorizer)处于开启状态时,可以启用自动更新功能.

发现类角色

默认ClusterRole 默认ClusterRoleBinding 描述
system:basic-user system:authenticated and system:unauthenticated groups 允许用户只读访问有关自己的基本信息。
system:discovery system:authenticated and system:unauthenticated groups 允许只读访问API discovery endpoints, 用于在API级别进行发现和协商。

面向用户的角色

一些默认角色并不包含system:前缀,它们是面向用户的角色。 这些角色包含超级用户角色(cluster-admin),即旨在利用ClusterRoleBinding(cluster-status)在集群范围内授权的角色, 以及那些使用RoleBinding(admin、edit和view)在特定命名空间中授权的角色。

默认ClusterRole 默认ClusterRoleBinding 描述
cluster-admin system:masters group 超级用户权限,允许对任何资源执行任何操作。 在ClusterRoleBinding中使用时,可以完全控制集群和所有命名空间中的所有资源。 在RoleBinding中使用时,可以完全控制RoleBinding所在命名空间中的所有资源,包括命名空间自己。
admin None 管理员权限,利用RoleBinding在某一命名空间内部授予。 在RoleBinding中使用时,允许针对命名空间内大部分资源的读写访问, 包括在命名空间内创建角色与角色绑定的能力。 但不允许对资源配额(resource quota)或者命名空间本身的写访问。
edit None 允许对某一个命名空间内大部分对象的读写访问,但不允许查看或者修改角色或者角色绑定。
view None 允许对某一个命名空间内大部分对象的只读访问。 不允许查看角色或者角色绑定。 由于可扩散性等原因,不允许查看secret资源。

Core Component Roles(核心组件角色)

默认ClusterRole 默认ClusterRoleBinding 描述
system:kube-scheduler system:kube-scheduler user 允许访问kube-scheduler组件所需要的资源。
system:kube-controller-manager system:kube-controller-manager user 允许访问kube-controller-manager组件所需要的资源。 单个控制循环所需要的权限请参阅控制器(controller)角色.
system:node system:nodes group (deprecated in 1.7) 允许对kubelet组件所需要的资源的访问,包括读取所有secret和对所有pod的写访问。 自Kubernetes 1.7开始, 相比较于这个角色,更推荐使用Node authorizer 以及NodeRestriction admission plugin, 并允许根据调度运行在节点上的pod授予kubelets API访问的权限。 自Kubernetes 1.7开始,当启用Node授权模式时,对system:nodes用户组的绑定将不会被自动创建。
system:node-proxier system:kube-proxy user 允许对kube-proxy组件所需要资源的访问。

其它组件角色

默认ClusterRole 默认ClusterRoleBinding 描述
system:auth-delegator None 允许委托认证和授权检查。 通常由附加API Server用于统一认证和授权。
system:heapster None Heapster组件的角色。
system:kube-aggregator None kube-aggregator组件的角色。
system:kube-dns kube-dns service account in the kube-systemnamespace kube-dns组件的角色。
system:node-bootstrapper None 允许对执行Kubelet TLS引导(Kubelet TLS bootstrapping)所需要资源的访问.
system:node-problem-detector None node-problem-detector组件的角色。
system:persistent-volume-provisioner None 允许对大部分动态存储卷创建组件(dynamic volume provisioner)所需要资源的访问。

控制器(Controller)角色

Kubernetes controller manager负责运行核心控制循环。 当使用--use-service-account-credentials选项运行controller manager时,每个控制循环都将使用单独的服务账户启动。 而每个控制循环都存在对应的角色,前缀名为system:controller:。 如果不使用--use-service-account-credentials选项时,controller manager将会使用自己的凭证运行所有控制循环,而这些凭证必须被授予相关的角色。 这些角色包括:

 1system:controller:attachdetach-controller
 2system:controller:certificate-controller
 3system:controller:cronjob-controller
 4system:controller:daemon-set-controller
 5system:controller:deployment-controller
 6system:controller:disruption-controller
 7system:controller:endpoint-controller
 8system:controller:generic-garbage-collector
 9system:controller:horizontal-pod-autoscaler
10system:controller:job-controller
11system:controller:namespace-controller
12system:controller:node-controller
13system:controller:persistent-volume-binder
14system:controller:pod-garbage-collector
15system:controller:replicaset-controller
16system:controller:replication-controller
17system:controller:resourcequota-controller
18system:controller:route-controller
19system:controller:service-account-controller
20system:controller:service-controller
21system:controller:statefulset-controller
22system:controller:ttl-controller

Permissive RBAC(宽泛的RBAC权限)

所谓 Permissive RBAC 是指授权给所有的 Service Accounts 管理员权限。

您可以使用RBAC角色绑定来复制一个宽泛的策略。

警告:以下政策略允许所有服务帐户作为集群管理员。 运行在容器中的任何应用程序都会自动接收服务帐户凭据,并且可以对API执行任何操作,包括查看secret和修改权限。 因此,并不推荐使用这种策略。

1kubectl create clusterrolebinding permissive-binding \
2  --clusterrole=cluster-admin \
3  --user=admin \
4  --user=kubelet \
5  --group=system:serviceaccounts