k8s系列-04-k8s的认证、授权和准入控制

k8s系列-04-k8s的认证、授权和准入控制

主旨

本节主要介绍一下，k8s客户端如何经过认证访问到apiserver，以及k8s如何授权，是怎么判定访问者拥有什么权限等内容。

认证

1、客户端认证

客户端认证也称为TLS双向认证，为什么这么说呢，是因为kubectl在访问apiserver的时候，apiserver也要认证kubectl是否正确，他们都会访问CA来进行验证，如下图：

2、Bearertoken

Bearertoken的方式，可以理解为apiserver将一个密码通过了非对称加密的方式告诉了kubectl，然后通过该密码进行相互访问，和TLS类似，但是少了CA，如下图：

3、Serviceaccount

上面客户端证书认证和Bearertoken的两种认证方式，都是外部访问apiserver的时候使用的方式，那么我们这次说的Serviceaccount是内部访问pod和apiserver交互时候采用的一种方式。

Serviceaccount包括了，namespace、token、ca，且通过目录挂载的方式给予pod，当pod运行起来的时候，就会读取到这些信息，从而使用该方式和apiserver进行通信。如下图：

授权-RBAC

认证我们介绍完了，不过仅仅是认证是不够的，认证只能确定访问者没有问题，那么访问者有什么权限呢？他能访问哪些东西呢？这时候我们就需要授权了。在k8s中的授权模式采用的是RBAC，即：基于角色的访问控制，分为以下三种类型来进行：

我们先说用户吧，用户在这里分为普通用户（User）比如我们上面说的kubectl，以及程序内部的用户（serviceaccept）比如pod：

然后咱们介绍下权限，权限主要根据两方面来划分，一个是资源（resource），另外一个就是具体的操作权限，比如新增，删除之类的，简单的来说就是curd（create、update、read、delete）。

最后我们是不是还剩下一个角色，那么角色我们主要分为三部分，且通过Rolebinding的方式来绑定，如下：

但是我们知道，k8s中有一个非常重要的概念，就是namespace，如果一个user只能访问一个namespace的话，那仅仅只通过上面的模式，是不是不太行，那么k8s是如何解决的呢？将Role放到了具体的namespace中，即如果你拥有了这个Role的角色，那么你只对当前Role所属的namespace有权限，如下：

那么问题又来了，如果有一个user，对好多个namespace有权限，是不是要归属很多role中，有没有一种简单的方式来解决这个问题呢？k8s就又引入了一种clusterRole的概念，顾名思义就是集群角色，这个角色凌驾于namespace之上，随之也引入了和rolebinding类似的clusterrolebinding，如下图：

Admissioncontrol

这个是什么意思呢，就是准入控制，比如控制谁让进入，不让谁进入，当经过认证和授权之后，这就是最后一步了，具体有哪些准入控制呢，k8s当中提供了很多个，当然了，你也可以添加多个，并不是说每次只能添加一个准入控制，执行的顺序，就是你添加准入控制的顺序，是串行的，如下图：

至此，本文结束，下面我们将简单说下集群方案对比。