说明：
基于角色的访问控制（rbac）是一种基于企业中单个用户的角色来管理对计算机或网络资源的访问的方法。
Kubernetes API.
k8s中的使用
RBAC使用rbac.authorization.k8s.io API group 来驱动认证，允许管理员通过Kubernetes API. 动态地配置访问策略
1.8之后的版本都是稳定版本，rbac.authorization.k8s.io/v1是它使用的API ，k8s集群要使用RBAC认证需要在API server上
开启该模式–authorization-mode=RBAC.
API概述
RBAC API声明了四种顶级的类型，用户可以像使用其他resource一样，使用kubectl操作它。可以通过kubectl apply -f (resource).yml 创建
1.Role and ClusterRole
在RBAC API中， 一个role包含了一系列的权限控制，role 使用role定义在一个namespace ，cluster-wide 使用cluster-wide定义集群的 面向–all-namespace的role
举例

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

该例子中，使用Role 类型给 default namespace定义了一个 pod-reader 的role ，针对 pods资源类型使用的规则包括
[“get”, “watch”, “list”]

ClusterRole也可以当作Role授予控制权限，但是它是集群级别的，可以有如下的用法：
cluster-scoped级别的资源 如node
非资源对象 endpoints
namespaced resources 如 pod
举例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

如上，创建了一个ClusterRole 类型的权限控制，叫做secret-reader ，针对secrets 资源类型使用的规则包括
[“get”, “watch”, “list”]

2.RoleBinding and ClusterRoleBinding

Role binding 是给一个用户，或者一系列用户赋权 ，它有一个subjects的概念包含（users，groups ，serviceaccount），对应关联的role 可以对一个namespaces 起作用，或者 ClusterRoleBinding.对集群级别起作用。
举例

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

如上例子中，创建了一个read-pods类型为RoleBinding ，针对default namespaces起作用， 它将用户 jane 与 Role类型的pod-reader 进行了绑定，允许该用户对default内的 pod 有pod-reader权限。

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "dave" to read secrets in the "development" namespace.
kind: RoleBinding
metadata:
  name: read-secrets
  namespace: development # This only grants permissions within the "development" namespace.
subjects:
- kind: User
  name: dave # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

rolebinding还可以引用clusterrole，以授予对rolebinding命名空间中clusterrole中定义的命名空间资源的权限。这允许管理员为整个集群定义一组公共角色，然后在多个名称空间中重用它们。
如上，即使下面的rolebinding引用了clusterrole，“dave” 也只能读取“development”命名空间（rolebinding的命名空间）中的secretes。
这样有个好处是所有权限可以统一管理，用到时候具体赋权，方便管理。

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

最后，可以使用clusterRoleBinding在集群级别和所有命名空间中授予权限。以上ClusterRoleBinding允许组“Manager”中的任何用户读取任何命名空间中的secrets。
还有一点需要注意 ：
不能修改绑定对象引用的角色或群集角色。试图更改绑定对象的roleref字段将导致验证错误。若要更改现有绑定对象上的roleref字段，必须删除并重新创建绑定对象。

Aggregated ClusterRoles
从1.9开始，可以使用aggregationrule将其他clusterroles组合起来创建clusterroles。聚合的ClusterRoles的权限由控制器管理，并通过联合与提供的标签选择器匹配的任何ClusterRole的规则来填充。聚合的ClusterRole示例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # Rules are automatically filled in by the controller manager.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aggregate-cron-tabs-edit
  labels:
    # Add these permissions to the "admin" and "edit" default roles.
    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:
    # Add these permissions to the "view" default role.
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch"]

Role的各种用法举例

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

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

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

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

Referring to Subjects
rolebinding或clusterrolebinding将角色绑定到受试者。主题可以是组、用户或服务帐户。
用户由字符串表示。它们可以是简单的用户名，如“alice”，电子邮件样式的名称，如“bob@example.com”，或者表示为字符串的数字标识。由kubernetes管理员来配置身份验证模块，以生成所需格式的用户名。rbac授权系统不需要任何特定格式。
但是，前缀system:是为kubernetes系统使用而保留的，因此管理员应确保用户名不会意外地包含此前缀。
kubernetes中的组信息目前由authenticator模块提供。与用户一样，组被表示为字符串，该字符串没有格式要求，只是保留了前缀system:。
服务帐户的用户名以system:serviceCaccount:prefix为前缀，并且属于以system:serviceCaccounts:prefix为前缀的组。

Role Binding 举例
仅仅展示subjetc部分

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

subjects:
- kind: Group
  name: "frontend-admins"
  apiGroup: rbac.authorization.k8s.io

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

集群中所有Controller Roles

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

常用的命令行

Create a Role named “pod-reader” that allows user to perform “get”, “watch” and “list” on pods:

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

Create a Role named “pod-reader” with resourceNames specified:

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

Create a Role named “foo” with apiGroups specified:

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

Create a Role named “foo” with subresource permissions:

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

Create a Role named “my-component-lease-holder” with permissions to get/update a resource with a specific name:

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

Creates a ClusterRole object. Examples:

Create a ClusterRole named “pod-reader” that allows user to perform “get”, “watch” and “list” on pods:

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

Create a ClusterRole named “pod-reader” with resourceNames specified:

kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

Create a ClusterRole named “foo” with apiGroups specified:

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

Create a ClusterRole named “foo” with subresource permissions:

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

Create a ClusterRole name “foo” with nonResourceURL specified:

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

Create a ClusterRole name “monitoring” with aggregationRule specified:

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

Grants a Role or ClusterRole within a specific namespace. Examples:

Within the namespace “acme”, grant the permissions in the admin ClusterRole to a user named “bob”:

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

Within the namespace “acme”, grant the permissions in the view ClusterRole to the service account in the namespace “acme” named “myapp” :

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

Within the namespace “acme”, grant the permissions in the view ClusterRole to a service account in the namespace “myappnamespace” named “myapp”:

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

kubectl create clusterrolebinding
Grants a ClusterRole across the entire cluster, including all namespaces. Examples:

Across the entire cluster, grant the permissions in the cluster-admin ClusterRole to a user named “root”:

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

Across the entire cluster, grant the permissions in the system:node-proxier ClusterRole to a user named “system:kube-proxy”:

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

Across the entire cluster, grant the permissions in the view ClusterRole to a service account named “myapp” in the namespace “acme”:

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

Service Account 权限
默认的rbac策略向控制平面组件、节点和控制器授予作用域权限，但不向kube系统命名空间之外的服务帐户授予权限（超出授予所有经过身份验证的用户的发现权限）。
这允许您根据需要将特定角色授予特定服务帐户。细粒度的角色绑定提供了更高的安全性，但需要更多的管理工作。而使用serviceaccount则让权限更为容器管理
例如，将“My namespace”内的只读权限授予“My SA”服务帐户

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

对default service account 赋权
如果应用程序未指定ServiceAccountName，则使用“默认”服务帐户

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

对kube-system 中default账户赋予超级管理员权限

kubectl create clusterrolebinding add-on-cluster-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:default

对指定namespace中所有的serviceaccount赋权

kubectl create rolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts:my-namespace \
  --namespace=my-namespace

授予超级用户对群集范围内所有服务帐户的访问权限（强烈建议）

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