容器云平台的基础安全和管理安全设计( 六 ) _云知道

Kubernetes有三种主要的身份验证方法，用于和API进行交互。官网列出了更多的认证方法，但以下三种是用户认证常见的方法。

静态密码
X.509客户端证书
OpenID Connect（OIDC）

其中，OpenID Connect基于OAuth 2.0协议。
结合kubernetes的支持能力以及常见的方案，容器云平台SSO参照实现方案可以采纳Dex或者Keycloak 。
构建最小权限授权管理机制
所有对容器云的访问均通过kubernetes api server实现，其中访问控制的规则也是在api server进行设置，在最新的Kubernetes中ABAC(基于属性的访问控制)已被RBAC取代，ABAC不建议api server上启用，需要使用RBAC，启用方式是：
–authorization-mode=RBAC
除此之外还有以下模式：
–authorization_mode=AlwaysDeny
–authorization_mode=AlwaysAllow
–authorization_mode=ABAC
–authorization_mode=Webhook
–authorization_mode=Node
容器云平台RBAC授权管理机制涉及的概念包括：
1．访问对象定义：
K8s对集群内部的对象以及对象上有的操作进行了规范，比如对象包括（不含CRD对象）：

Pods
ConfigMaps
Deployments
Nodes
Secrets
Namespaces

2．对象操作定义：
资源对象的可能存在的操作有：

create
get
delete
list
update
edit
watch
exec

3．角色/集群角色定义：
角色是针对以上资源上的一组操作的集合
k8s对于role进行了区分，分为角色(Role)和集群角色(ClusterRole)，其中在角色Role中，定义的规则只适用于单个命名空间，也就是和namespace关联的，而ClusterRole是集群范围内的，因此定义的规则不受命名空间的约束。
4．用户/服务账户/组定义：
在Kubernetes集群中有存在两类用户：
service accounts：由Kubernetes进行管理的特殊用户；
user（普通用户）：普通用户是由外部应用进行管理的用户。
Group：组，这是用来关联多个账户的，集群中有一些默认创建的组，比如cluster-admin
对于普通用户，Kubernetes管理员只负责为其分配私钥。普通用户可能来自于Keystone或ldap中，或者甚至是存储在文件中的用户名和密码列表。在Kubernetes中，没有表达普通用户的对象，因此，也就不能通过API将普通用户添加到集群中。
而Service Account是由Kubernetes API管理的用户，它们被绑定到特定的命名空间中，并由API服务器自动创建或通过API调用手动创建。Service Account与存储在Secrets的一组证书相关联，这些凭据被挂载到pod中，以允许集群中进程与Kubernetes API进行通信。
API请求要么来自于普通用户或Service Account，或来自于匿名请求。这就意味着集群内外部的所有进程(从来自于用户使用kubectl输入的请求，或来自于Nodes中kubelet的请求，或来自控制板的成员的请求)都需要进行认证才能与API server进行交互。
5．角色绑定/集群角色绑定定义：
RoleBinding和ClusterRoleBinding：角色绑定和集群角色绑定，简单来说就是把声明的Subject和我们的Role进行绑定的过程(给某个用户绑定上操作的权限)，二者的区别也是作用范围的区别：RoleBinding只会影响到当前namespace下面的资源操作权限，而ClusterRoleBinding会影响到所有的namespace 。
在有以上定义的基础上，容器云平台的基于rbac管理模型下的权限管理方式：某一用户(service account或者User)通过角色绑定定义了该用户具有哪些角色，该角色详细记录具有对哪些对象的那些操作，即改用户具有了对哪些对象进行哪些操作的能力。