Kubernetes详解（五十二）——Kubernetes访问控制

今天继续给大家介绍Linux运维相关知识，本文主要内容是Kubernetes访问控制

一、Kubernetes授权简介

Kubernetes集群的授权是基于插件形式的，常见的授权方式有以下四种：
1、Node（节点认证）
2、ABAC（基于属性的访问控制）
3、RBAC（基于角色的访问控制）
4、Webhook（基于HTTP回调机制的访问控制）
我们常见的授权方式为RBAC，即基于角色的访问控制。

二、RBAC简介

RBAC，即Role-Based Access Controll，基于角色的访问控制，使用rbac.authorization.k8s.io的API Group实现授权决策，并允许管理员通过Kubernetes API动态配置策略。
在RBAC的授权方式中，权限与“角色”有关，每个角色都对应者不同的权限，当我们需要给某个用户授权时，需要把拥有该权限的角色赋予该用户。一个用户可以拥有多个角色，一个角色也可以被多个用户所拥有。注意，RBAC模式下，用户所对应的权限没有“否定”的，即一个Role总是规定了可以做什么，并没有规定该Role禁止做什么。这样一个用户所拥有的权限就是该用户所绑定的角色的权限的累积。RBAC的权限控制如下图所示：

在Kubernetes集群的RBAC授权机制中，考虑到了namespace名称空间的隔离性，角色被分为普通的Role和ClusterRole两种，一个普通Role与一个namespace名称空间所绑定，仅具有对该名称空间操作的权限，对其他的名称空间没有操作权限。而ClusterRole对整个集群内的所有namespace名称空间都具有操作权限。因此，我们可以根据实际情况来创建不同的角色，以方便我们的管理。
除了角色之外，Kubernetes集群还提供了两种绑定方式，即Rolebinding和ClusterRolebinding，绑定方式用于将Kubernetes集群中的用户和角色绑定到一起，Rolebinding用于将Role绑定到用户上，此时用户具有对该Role对应的namespace的权限；ClusterRolebinding用于将CLusterRole绑定到用户上，此时用户具有对该ClusterRole对整个集群的权限。此外，Kubernetes集群还支持Rolebinding将ClusterRole绑定到用户上，此时用户只拥有对该Role对应的namespace的权限。这种另类的绑定方式主要运用到以下场景：
例如，我们的Kubernetes集群中有100个namespace，如果我要配置100个用户分别管理这100个namespace，那么我如果采用Rolebinding绑定到Role的方式，就必须创建100个Rolebinding和100个Role，但是如果采用Rolebinding绑定到ClusterRole的方式，就可以只创建100个Rolebinding和一个ClusterRole，这就大大减少了创建Role所需要的资源了。
Kubernetes集群下Role、ClusterRole、Rolebinding和ClusterRolebinding如下所示：

关于以上三种方式的实际配置，请参考以下文章：
Kubernetes详解（五十三）——Kubernetes Role创建和Rolebinding
Kubernetes详解（五十四）——Kubernetes ClusterRole创建和ClusterRolebinding
Kubernetes详解（五十五）——ClusterRole与RoleBinding
原创不易，转载请说明出处：https://blog.csdn.net/weixin_40228200