k8s的认证受权

1、ServiceAccount

Service account是为了方便Pod里面的进程调用Kubernetes API或其余外部服务而设计的。它与User account不一样

 

User account是为人设计的，而service account则是为Pod中的进程调用Kubernetes API而设计；

User account是跨namespace的，而service account则是仅局限它所在的namespace；

每一个namespace都会自动建立一个default service account

Token controller检测service account的建立，并为它们建立secret

开启ServiceAccount Admission Controller后

每一个Pod在建立后都会自动设置spec.serviceAccount为default（除非指定了其余ServiceAccout）

验证Pod引用的service account已经存在，不然拒绝建立

若是Pod没有指定ImagePullSecrets，则把service account的ImagePullSecrets加到Pod中

每一个container启动后都会挂载该service account的token和ca.crt到/var/run/secrets/kubernetes.io/serviceaccount/

 当建立 pod 的时候，若是没有指定一个 service account，系统会自动在与该pod 相同的 namespace 下为其指派一个default service account。而pod和apiserver之间进行通讯的帐号，称为serviceAccountName。

 

2、RBAC----基于角色的访问控制

 Kubernetes的受权是基于插件形式的，其经常使用的受权插件有如下几种：

 

Node（节点认证）

ABAC(基于属性的访问控制)

RBAC（基于角色的访问控制）

Webhook（基于http回调机制的访问控制）

 让一个用户（Users）扮演一个角色（Role），角色拥有权限，从而让用户拥有这样的权限，随后在受权机制当中，只须要将权限授予某个角色，此时用户将获取对应角色的权限，从而实现角色的访问控制。

 

基于角色的访问控制（Role-Based Access Control, 即”RBAC”）使用”rbac.authorization.k8s.io” API Group实现受权决策，容许管理员经过Kubernetes API动态配置策略。

 

在k8s的受权机制当中，采用RBAC的方式进行受权，其工做逻辑是　　把对对象的操做权限定义到一个角色当中，再将用户绑定到该角色，从而使用户获得对应角色的权限。此种方式仅做用于名称空间当中，这是什么意思呢？当User1绑定到Role角色当中，User1就获取了对该NamespaceA的操做权限，可是对NamespaceB是没有权限进行操做的，如get，list等操做。

另外，k8s为此还有一种集群级别的受权机制，就是定义一个集群角色（ClusterRole），对集群内的全部资源都有可操做的权限，从而将User2，User3经过ClusterRoleBinding到ClusterRole，从而使User二、User3拥有集群的操做权限。Role、RoleBinding、ClusterRole和ClusterRoleBinding的关系

 

可是这里有2种绑定ClusterRoleBinding、RoleBinding。也能够使用RoleBinding去绑定ClusterRole。

当使用这种方式进行绑定时，用户仅能获取当前名称空间的全部权限。为何这么绕呢？？举例有10个名称空间，每一个名称空间都须要一个管理员，而该管理员的权限都是一致的。那么此时须要去定义这样的管理员，使用RoleBinding就须要建立10个Role，这样显得更加繁重。为此当使用RoleBinding去绑定一个ClusterRole时，该User仅仅拥有对当前名称空间的集群操做权限，换句话说，此时只须要建立一个ClusterRole就解决了以上的需求。

 

 这里要注意的是：RoleBinding仅仅对当前名称空间有对应的权限。

 

在RBAC API中，一个角色包含了一套表示一组权限的规则。 权限以纯粹的累加形式累积（没有”否认”的规则）。 角色能够由命名空间（namespace）内的Role对象定义，而整个Kubernetes集群范围内有效的角色则经过ClusterRole对象实现。

 

 

 4、RBAC的三种受权访问

RBAC不单单能够对user进行访问权限的控制，还能够经过group和serviceaccount进行访问权限控制。当咱们想对一组用户进行权限分配时，便可将这一组用户归并到一个组内，从而经过对group进行访问权限的分配，达到访问权限控制的效果。

 

从前面serviceaccount咱们能够了解到，Pod能够经过 spec.serviceAccountName来定义其是以某个serviceaccount的身份进行运行，当咱们经过RBAC对serviceaccount进行访问受权时，便可以实现Pod对其余资源的访问权限进行控制。也就是说，当咱们对serviceaccount进行rolebinding或clusterrolebinding，会使建立Pod拥有对应角色的权限和apiserver进行通讯。