kubernetes的RBAC

时间：Dec. 14, 2018 分类：容器

目录：

Kubernetes RBAC

基于角色的访问控制(RBAC)授权在1.6版本处于Beat阶段，在1.8版本正式应用了RBAC。

RBAC是一种控制访问Kubernetes API的机制

Role与ClusterRole

两者都是定义角色，角色包含了一组权限规则

Role

Role是应用于单个命名空间的

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

ClusterRole

而ClusterRole可以用于单个命名空间也可以用于整个集群

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  # 鉴于ClusterRole是集群范围对象，所以这里不需要定义"namespace"字段
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

RoleBinding与ClusterRoleBinding

RoleBinding

和上边一样

RoleBinding用于用户空间的对象授权

# 以下角色绑定定义将允许用户"jane"从"default"命名空间中读取pod。
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

RoleBinding对象也可以引用一个ClusterRole对象用于在RoleBinding所在的命名空间内授予用户对所引用的ClusterRole中定义的命名空间资源的访问权限。

apply对应的Role: pod-reader和RoleBinding: read-pods

$ kubectl get pods --as jane
NAME                        READY   STATUS    RESTARTS   AGE
producer-consumer           2/2     Running   16         3d
$ kubectl get deployments --as jane
Error from server (Forbidden): deployments.extensions is forbidden: User "jane" cannot list resource "deployments" in API group "extensions" in the namespace "default"
$ kubectl --namespace=kube-system  get pods --as jane
Error from server (Forbidden): pods is forbidden: User "jane" cannot list resource "pods" in API group "" in the namespace "kube-system"

可以看到以jane用户进行get pods是没有任何问题的，而get deployments会报没有权限的错误，在非default进行get pods

ClusterRoleBinding

集群范围的权限授予则通过ClusterRoleBinding对象完成

# 以下角色绑定允许用户"dave"读取"development"命名空间中的secret。
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets
  namespace: development # 这里表明仅授权读取"development"命名空间中的资源。
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

对于用户组进行角色绑定

# 以下`ClusterRoleBinding`对象允许在用户组"manager"中的任何用户都可以读取集群中任何命名空间中的secret。
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Aggregated ClusterRoles

这是1.9版本引入的新功能，简而言之，你可以利用标签来组合一些列的ClusterRoles，具体样例如下：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
# 所有带有 rbac.example.com/aggregate-to-monitoring: "true" 这个标签的都会被组合
# 然后自动生成 rules
rules: []

限制

可以进行限制的范围

  • 集群范围资源（例如节点，即node）
  • 非资源类型endpoint（例如"/healthz"）
  • 跨所有命名空间的命名空间范围资源（例如pod，需要运行命令kubectl get pods --all-namespaces来查询集群中所有的pod）

子资源

大多数资源由代表其名字的字符串表示，例如"pods"，就像相关的API endpoint的URL一样，然而这些API还可能包含子资源，例如pods的logs，其URL为

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

对于这种情况，pods是命名空间资源，而logs是pods的子资源，所以resources要通过斜线来区分即"pods/log"

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

resourceNames

resourceNames可以指定resource的具体资源列表，这样就只能限制指定的资源

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  resources: ["configmap"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

这样就是只有configmap的name为my-configmap的资源，如果设置了resourceNames，verbs不能是list、watch、create或者deletecollection，因为这些是不会出现在API请求的URL中

一些例子

允许读取core API Group中定义的资源"pods"：

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

允许读写在"extensions"和"apps" API Group中定义的"deployments"：

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

允许读取"pods"以及读写"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"]

允许读取core API Group中的"nodes"资源（由于Node是集群级别资源，所以此ClusterRole定义需要与一个ClusterRoleBinding绑定才能有效）：

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

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

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

对角色绑定主体的引用

RoleBinding或者ClusterRoleBinding将角色绑定到主体上，即subject，绑定主体可以是User，Group或者Service Accounts（服务账户）

  • 用户可以是纯粹的而用户名，例如alice，也可以是电子邮件风格的名字，例如"bob@example.com"，或者是纯数字的ID。需要注意的是前缀system:是需要被kubernetes系统保留的，只要保证用户名不是使用此前缀即可
  • 用户组和用户名一样由字符串表示，同样system:是需要被kubernetes系统保留的
  • 服务账户拥有包含system:serviceaccount:前缀的用户名，并属于拥有system:serviceaccounts:前缀的用户组

角色绑定的一些例子

一个名为"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

所有认证过的用户（version 1.5+）：

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

所有未认证的用户（version 1.5+）：

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

所有用户（version 1.5+）：

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  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:unauthenticatedgroups 允许用户只读访问有关自己的基本信息。
system:discovery system:authenticated and system:unauthenticatedgroups 允许只读访问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资源。

核心组件角色

默认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将会使用自己的凭证运行所有控制循环，而这些凭证必须被授予相关的角色。 这些角色包括：

  • system:controller:attachdetach-controller
  • system:controller:certificate-controller
  • system:controller:cronjob-controller
  • system:controller:daemon-set-controller
  • system:controller:deployment-controller
  • system:controller:disruption-controller
  • system:controller:endpoint-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:replicaset-controller
  • system:controller:replication-controller
  • system:controller:resourcequota-controller
  • system:controller:route-controller
  • system:controller:service-account-controller
  • system:controller:service-controller
  • system:controller:statefulset-controller
  • system:controller:ttl-controller

初始化与预防权限升级

RBAC API会阻止用户通过编辑角色或者角色绑定来升级权限。

用户只有在拥有了角色所包含的所有权限的条件下才能创建/更新一个角色，这些操作还必须在角色所处的相同范围内进行（对于ClusterRole来说是集群范围，对于Role来说是在与角色相同的命名空间或者集群范围），例如，如果用户"user-1"没有权限读取集群范围内的secret列表，那么他也不能创建包含这种权限的ClusterRole。为了能够让用户创建/更新角色，需要：

  1. 授予用户一个角色以允许他们根据需要创建/更新Role或者ClusterRole对象
  2. 授予用户一个角色包含他们在Role或者ClusterRole中所能够设置的所有权限。如果用户尝试创建或者修改Role或者ClusterRole以设置那些他们未被授权的权限时，这些API请求将被禁止

同理权限绑定也是一样的，需要

  1. 授予用户一个角色以允许他们根据需要创建/更新RoleBinding或者ClusterRoleBinding对象。
  2. 授予用户绑定某一特定角色所需要的权限：
  • 隐式地，通过授予用户所有所引用的角色中所包含的权限
  • 显式地，通过授予用户在特定Role（或者ClusterRole）对象上执行bind操作的权限

示例ClusterRole和RoleBinding将允许用户”user-1”授予其它用户”user-1-namespace”命名空间内的admin、edit和view等角色和角色绑定

apiVersion: rbac.authorization.k8s.io/v1beta1
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: ["admin","edit","view"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
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

命令行工具

kubectl create rolebinding

在某一特定命名空间内授予Role或者ClusterRole。

示例如下：

在名为"acme"的命名空间中将admin ClusterRole授予用户"bob"：

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

在名为"acme"的命名空间中将view ClusterRole授予服务账户"myapp"：

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

kubectl create clusterrolebinding

在整个集群中授予ClusterRole，包括所有命名空间。示例如下：

在整个集群范围内将cluster-admin ClusterRole授予用户"root"：

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

在整个集群范围内将system:node ClusterRole授予用户"kubelet"：

kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet

在整个集群范围内将view ClusterRole授予命名空间"acme"内的服务账户"myapp"：

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

服务账户（Service Account）权限

默认的RBAC策略将授予控制平面组件（control-plane component）、节点（node）和控制器（controller）一组范围受限的权限， 但对于”kube-system”命名空间以外的服务账户，则不授予任何权限（超出授予所有认证用户的发现权限）。

这一点允许您根据需要向特定服务账号授予特定权限。 细粒度的角色绑定将提供更好的安全性，但需要更多精力管理。 更粗粒度的授权可能授予服务账号不需要的API访问权限（甚至导致潜在授权扩散），但更易于管理。

从最安全到最不安全可以排序以下方法：

  1. 对某一特定应用程序的服务账户授予角色（最佳实践）

要求应用程序在其pod规范（pod spec）中指定serviceAccountName字段，并且要创建相应服务账户（例如通过API、应用程序清单或者命令kubectl create serviceaccount等）。

例如，在"my-namespace"命名空间中授予服务账户"my-sa"只读权限：

kubectl create rolebinding my-sa-view \
  --clusterrole=view \
  --serviceaccount=my-namespace:my-sa \
  --namespace=my-namespace
  1. 在某一命名空间中授予"default"服务账号一个角色

如果一个应用程序没有在其pod规范中指定serviceAccountName，它将默认使用"default"服务账号。

注意：授予"default"服务账号的权限将可用于命名空间内任何没有指定serviceAccountName的pod。

下面的例子将在”my-namespace”命名空间内授予”default”服务账号只读权限：

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

目前，许多[加载项（addon）]（/ docs / concepts / cluster-administration / addons /）作为”kube-system”命名空间中的”default”服务帐户运行。 要允许这些加载项使用超级用户访问权限，请将cluster-admin权限授予”kube-system”命名空间中的”default”服务帐户。 注意：启用上述操作意味着”kube-system”命名空间将包含允许超级用户访问API的秘钥。

kubectl create clusterrolebinding add-on-cluster-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:default
  1. 为命名空间中所有的服务账号授予角色

如果您希望命名空间内的所有应用程序都拥有同一个角色，无论它们使用什么服务账户，您可以为该命名空间的服务账户用户组授予角色。

下面的例子将授予“my-namespace”命名空间中的所有服务账户只读权限：

kubectl create rolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts:my-namespace \
  --namespace=my-namespace
  1. 对集群范围内的所有服务账户授予一个受限角色（不鼓励）

如果您不想管理每个命名空间的权限，则可以将集群范围角色授予所有服务帐户。

下面的例子将所有命名空间中的只读权限授予集群中的所有服务账户：

kubectl create clusterrolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts
  1. 授予超级用户访问权限给集群范围内的所有服务帐户（强烈不鼓励）

如果您根本不关心权限分块，您可以对所有服务账户授予超级用户访问权限。

警告：这种做法将允许任何具有读取权限的用户访问secret或者通过创建一个容器的方式来访问超级用户的凭据。

kubectl create clusterrolebinding serviceaccounts-cluster-admin \
  --clusterrole=cluster-admin \
  --group=system:serviceaccounts

宽泛的RBAC权限

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

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

kubectl create clusterrolebinding permissive-binding \
  --clusterrole=cluster-admin \
  --user=admin \
  --user=kubelet \
  --group=system:serviceaccounts

创建基于linux用户的RBAC权限限制

生成私有密钥

$ mkdir /etc/kubernetes/pki/certs
$ openssl genrsa -out /etc/kubernetes/pki/certs/develop.key 2048

用私钥生成证书，CN表示用户名，O表示用户组

$ openssl req -new -key /etc/kubernetes/pki/certs/develop.key -out /etc/kubernetes/pki/certs/develop.csr -subj "/CN=develop/O=example"

然后用CA证书来给刚才生成的证书来签名

$ openssl x509 -req -in /etc/kubernetes/pki/certs/develop.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out /etc/kubernetes/pki/certs/develop.crt -days 365

设置 cluster

以下命令均在需要进授权的用户下操作

kubectl config set-cluster k8s.develop --server="https://172.19.0.9:6443" --certificate-authority="/etc/kubernetes/pki/ca.crt" --embed-certs=true
  • 可以指定配置--kubeconfig=/etc/kubernetes/develop.conf

设置私钥以及已签名证书

kubectl config set-credentials develop --client-certificate=/etc/kubernetes/pki/certs/develop.crt  --client-key=/etc/kubernetes/pki/certs/develop.key --embed-certs=true

设置context

kubectl config set-context develop-context --cluster=k8s.develop --user=develop
kubectl config use-context develop-context

如果kubectl不自动补全在用户的.bashrc文件中加入以下内容

source <(kubectl completion bash)

这些都可以统一做到/etc/bashrc的

查看当前

$ kubectl config get-contexts
CURRENT   NAME              CLUSTER       AUTHINFO   NAMESPACE
*         develop-context   k8s.develop   develop    
$ kubectl get pods
Error from server (Forbidden): pods is forbidden: User "develop" cannot list resource "pods" in API group "" in the namespace "default"

进行授权

一下操作需要通过admin等可以进行授权的用户进行操作

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: cluster-readonly
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - pods/attach
  - pods/exec
  - pods/portforward
  - pods/proxy
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - configmaps
  - endpoints
  - persistentvolumeclaims
  - replicationcontrollers
  - replicationcontrollers/scale
  - secrets
  - serviceaccounts
  - services
  - services/proxy
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - bindings
  - events
  - limitranges
  - namespaces/status
  - pods/log
  - pods/status
  - replicationcontrollers/status
  - resourcequotas
  - resourcequotas/status
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - apps
  resources:
  - deployments
  - deployments/rollback
  - deployments/scale
  - statefulsets
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - autoscaling
  resources:
  - horizontalpodautoscalers
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - batch
  resources:
  - cronjobs
  - jobs
  - scheduledjobs
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - extensions
  resources:
  - daemonsets
  - deployments
  - ingresses
  - replicasets
  verbs:
  - get
  - list
  - watch

权限绑定

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: cluster-readonly
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-readonly
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: develop

apply之后再被授权用户下机型测试权限

$ kubectl get pods
NAME                        READY   STATUS    RESTARTS   AGE
producer-consumer           2/2     Running   22         3d19h