K8S的认证部分， ServiceAccount以及RBAC 。

授权插件

  1. Node
  2. ABAC
  3. RBAC
  4. Webhook

常用的授权插件就是RBAC

基于角色的授权和访问控制

基于角色的访问控制，就是将权限授予Role，而不是User。 将权限的控制授予Role， 将User分配到Role。默认的是拒绝全部， 无法也无需定义拒绝权限，定义的Permission是许可访问的权限。

  1. 角色，User Accouts OR Service Accounts.
  2. 许可， Permission分为两个部分：Operation 以及 Object.

角色以及角色绑定

Role – RoleBinding

Role 和 RoleBinding 是建立和控制 NameSpace 级别的权限。

集群角色以及集群角色绑定

ClusterRole – ClusterRoleBinding

Cluster 和 ClusterBinding 是建立和控制 Cluster 级别的权限。

NOTE： 特殊的情况，可以对名称空间级别的

特殊的绑定方式

ClusterRole – RoleBinding

可以使用 RoleBinding 绑定 ClusterRole， 那么这种情况下，Role只是具有NameSpace的权限。解释一下：雷在同一个Cluster中有多个不同的NameSpace，我需要对每个NameSpace都授权相同的权限，这种场景下:

  • 如果使用RoleBinding 去绑定一个Role，那么每一个NameSpace都需要建立各自的 RoleBinding，并且都要各自绑定到Role。

  • 如果建立一个ClusterRole, 使用RoleBinding绑定到ClusterRole上面，那么我只需要定义一个即可在全部集群范围内生效这个权限。这样的就相当于批量的进行Role的授权。

相关命令

命令不做过多的解释，所有的资源可以通过explain获取，主要是记录逻辑和思路。

~]$ kubectl create role testrole --verb=get,list,watch --resources=pods -o yaml
~]$ kubectl get role
~]$ kubectl describe role pods-reader
~]$ kubectl create rolebinding test-rolebinding --role=testrole --user=testuser -o yaml
~]$ kubectl explain rolebinding
~]$ kubectl config use-context USERNAME@kubernetes
~]$ kubectl create clusterrole test-clusterrole --verb=get,list,watch --resource=pods -o yaml 
~]$ kubectl explain clusterrole
~]$ kubectl get clusterrole
~]$

其他补充

在RBAC中可以存在三类组件：

  1. user
  2. group
  3. service account

创建Pod的过程中可以指定一个值叫做ServiceAccountName，如果授权ServiceAccount高等级的权限，那么，Pod会以这个Account运行，那么Pod中的应用程序也会有ServiceAccount的权限。也就是提高了Pod应用程序的等级，使得Pod可以对K8S的相关资源进行管理和配置。