(一)、RBAC概述

在K8S中授权ABAC（基于属性的访问控制）、RBAC（基于访问的访问控制）、Webhook、Node、AlwaysDeny（一直拒绝）和AlwaysAllow(一直访问)等6中模式，从1.6版本起，K8S默认启用RBAC访问控制策略，目前RBAC已作为稳定的功能，通过启用-authorization-mode=RBAC 来启用RABC.

在RBAC api中，通过如下步骤进行授权： 1、定义角色：在定义角色时会指定此角色对于资源访问控制的规则； 2、绑定角色：将主体与角色进行绑定，对用户进行访问授权；

(二)、RBAC资源对象说明

RBAC引入了四个新的顶级资源对象。Role、ClusterRole、RoleBinding、 ClusterRoleBinding。同其他 API 资源对象一样，用户可以使用 kubectl 或者 API 调用等 方式操作这些资源对象。

2.1、角色

一个角色就是一组权限的集合，这里的权限都是许可形式的，不存在拒绝的规则。在一个 命名空间中，可以用角色来定义一个角色，如果是集群级别的，就需要使用 ClusterRole 了。角色只能对命名空间内的资源进行授权，下面的例子中定义的角色具备读取Pod的权限:

[root@k8s-master role]# cat role.yaml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: prod-read

rules:
- apiGroups: [""]
  resources: ["prod"]
  verbs: ["get","watch","list"]
[root@k8s-master role]# kubectl apply -f role.yaml
role.rbac.authorization.k8s.io/prod-read created
[root@k8s-master role]# kubectl get role -owide
NAME        CREATED AT
prod-read   2022-01-04T09:55:05Z

集群角色ClusterRole能够被授予如下资源权限： 集群范围的资源（类似于Node） 非资源端点（类似于healthz） 集群中所有命名空间资源（类似于Pod）

下面是授予集群角色读取password字典文件访问权限

[root@k8s-master role]# kubectl apply -f clusterrole.yaml
clusterrole.rbac.authorization.k8s.io/secret-reader created
[root@k8s-master role]# cat clusterrole.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get","watch","list"]

2.2、角色绑定和集群角色绑定

角色绑定用于将角色一一个或一组用户进行绑定，从而实现对用户进行授权的目的。主体分为用户、组和服务账号。角色绑定也可以分为普通角色绑定和集群角色绑定。角色绑定只能引用到同一个命名空间下得角色。如，在default命名空间中角色绑定将kevin用户和prod-reader角色进行绑定，授权了Kevin能够访问default命名空间先的pod

[root@k8s-master role]# kubectl apply -f role-bond.yml
rolebinding.rbac.authorization.k8s.io/read-pods created
[root@k8s-master role]# cat role-bond.yml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: kevin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
[root@k8s-master role]# kubectl get role,rolebinding -owide
NAME                                       CREATED AT
role.rbac.authorization.k8s.io/prod-read   2022-01-04T09:55:05Z

NAME                                              ROLE              AGE    USERS   GROUPS   SERVICEACCOUNTS
rolebinding.rbac.authorization.k8s.io/read-pods   Role/pod-reader   110s   kevin

角色绑定也可以通过引用集群角色授予访问权限，当主体对资源的访问仅限于本命名空间，这就允许管理员定义整个集群的公共角色集合，然后在多个命名空间中进行复用

2.3、资源

在k8s中，主要的资源包括：pod、node、service、deployment、replicasets、statefulsets、namespace、persistents、secret、configmap等等，有些资源下边存在子资源。

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

可以对pod和pods/log进行访问

[root@k8s-master role]# kubectl apply -f  pod-log
role.rbac.authorization.k8s.io/pod-and-pod-logs-reader created
[root@k8s-master role]# cat pod-log
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 namespace: default
 name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods","pods/log"]
  verbs: ["get","list"]

通过resourceNames指定特定的资源实例，以限制角色只能够对实例进行访问控制

[root@k8s-master role]# kubectl apply -f  resource-access.yml
role.rbac.authorization.k8s.io/configmap-updater created
[root@k8s-master role]# cat resource-access.yml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["my-confi

2.4、主体

RBAC授权中的主体可以是组，用户或者服务帐户。用户通过字符串表示，比如“alice”、“kevin"具体的形式取决于管理员在认证模块中所配置的用户名。system:被保留作为用来Kubernetes系统使用，因此不能作为用户的前缀。组也有认证模块提供，格式与用户类似。 角色绑定主体的列子有如下： 1.名称为 “alice@example.com”用户：

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

2.名称为“frontend-admins”的组：

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

3.在kube-system命名空间中，名称为“default”的服务帐户：

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

4.在“qa”命名空间中，所有的服务帐户：

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

5.所有的服务帐户：

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

6.所有被认证的用户 (version 1.5+):

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

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

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

8.所有用户(version 1.5+):

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

（三）、命令行工具

K8S可以通过命令行工具进行角色绑定

3.1、kubecet create rolebinding

###在test命名空间中，将admin角色授权给bob
[root@k8s-master role]# kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=test
rolebinding.rbac.authorization.k8s.io/bob-admin-binding created
###在test命名空间中，将admin集群角色授予acme:myapp服务账号
[root@k8s-master role]# kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=test
rolebinding.rbac.authorization.k8s.io/myapp-view-binding created

3.2、kubectl create clusterrolebinding

在整个集群中进行角色绑定： 1.在整个集群中，授予”cluster-admin“集群角色给”root“用户：

[root@k8s-master role]# kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
clusterrolebinding.rbac.authorization.k8s.io/root-cluster-admin-binding created

2.在整个集群中，授予”system:node”集群角色给“kubelet”用户：

[root@k8s-master role]# kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet
clusterrolebinding.rbac.authorization.k8s.io/kubelet-node-binding created

3.在整个集群中，授予”view”集群角色给”acme:myapp”服务帐户：

[root@k8s-master role]# kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
clusterrolebinding.rbac.authorization.k8s.io/myapp-view-binding created

（四）、服务账号权限

默认情况下，RBAC策略授予控制板组件、Node和控制器作用域的权限，但是未授予“kube-system”命名空间外服务帐户的访问权限。这就允许管理员按照需要将特定角色授予服务帐户。 从最安全到最不安全的顺序，方法如下：

1）授予角色给一个指定应用的服务帐户(最佳实践)

这要求在Pod规格中指定serviveAccountName，同时此服务帐户已被创建(通过API、kubectl create serviceaccount等)。例如，在“test”命名空间内，授予”my-sa”服务帐户“view”集群角色：

[root@k8s-master role]# kubectl create rolebinding my-sa-view --clusterrole=view --serviceaccount=my-namespace:my-sa  --namespace=test
rolebinding.rbac.authorization.k8s.io/my-sa-view created

2）在一个命名空间授予“view”集群角色给“default”服务帐户

如果应用没有指定serviceAccountName，它将使用”default” 服务帐户。例如，例如，在“test”命名空间内，授予”default”服务帐户“view”集群角色：

[root@k8s-master role]# kubectl create rolebinding default-view --clusterrole=view  --serviceaccount=test:default --namespace=test
rolebinding.rbac.authorization.k8s.io/default-view created

当前，在”kube-system“命名空间中，很多插件作为”default“服务帐户进行运行。为了允许超级用户访问这些插件，在“kube-system”命名空间中授予”cluster-admin“角色给”default”帐户。

[root@k8s-master role]# kubectl create clusterrolebinding add-on-cluster-admin  --clusterrole=cluster-admin --serviceaccount=kube-system:default
clusterrolebinding.rbac.authorization.k8s.io/add-on-cluster-admin created

3）在一个命名空间中，授予角色给所有的服务帐户：

如果希望在一个命名空间中的所有应用都拥有一个角色，而不管它们所使用的服务帐户，可以授予角色给服务帐户组。例如，在“my-namespace”命名空间中，将”view“集群角色授予“system:serviceaccounts:my-namespace“组：

[root@k8s-master role]# kubectl create rolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts:test  --namespace=test
rolebinding.rbac.authorization.k8s.io/serviceaccounts-view created

4）在整个集群中授予一个角色给所有的服务帐户 (不推荐)

如果不想按照每个命名空间管理权限，可以在整个集群的访问进行授权。例如，在整个集群层面，将”view“集群角色授予“sytem:serviceaccounts“：

[root@k8s-master role]# kubectl create clusterrolebinding serviceaccounts-view --clusterrole=view  --group=system:serviceaccounts
clusterrolebinding.rbac.authorization.k8s.io/serviceaccounts-view created

5）在整个集群中授予超级用户访问所有的服务帐户 (强烈不推荐)

如果对访问权限不太重视，可以授予超级用户访问所有的服务帐户。

[root@k8s-master role]# kubectl create clusterrolebinding serviceaccounts-cluster-admin --clusterrole=cluster-admin --group=system:serviceaccounts
clusterrolebinding.rbac.authorization.k8s.io/serviceaccounts-cluster-admin created

6）宽松的RBAC权限

下面的策略允许所有的服务帐户作为集群管理员。在容器中运行的应用将自动的收取到服务帐户证书，并执行所有的API行为。包括查看保密字典恩将和修改权限，这是不被推荐的访问策略。

[root@k8s-master role]# kubectl create clusterrolebinding permissive-binding  --clusterrole=cluster-admin  --user=admin  --user=kubelet --group=system:serviceaccounts
clusterrolebinding.rbac.authorization.k8s.io/permissive-binding created