【云原生Kubernetes系列第六篇】Kubernetes的认证和授权

一、认证的密码学原理

什么是认证呢，比如说你去找工作，你说你是清华大学毕业的，面试官可能会有些质疑，但当你把清华大学的学位证拿出来的时候，面试官就信了，这个学位证就是对你的一种认证。当我们在上网的时候，地址栏中网址的前面都会加上https，这表明使用了https协议，有些浏览器会在https前面有一个绿色的小锁标志，这说明该网址经过了https协议认证的，是可信的，这也是一种认证，这个认证就跟Kubernetes里面的认证十分相似了。

下面解释一下密码学的两个概念

1.1 对称加密

比如说我们有一串数据“小姐姐好可爱”通过对称加密的算法加密后传输，传输过程中的数据就是一串看起来乱码的数据，接收端再进行对称解密，接受到原本的数据“小姐姐好可爱”。

1.2 非对称加密

起初也是一个明文“ 小姐姐好可爱 ”，使用非对称加密的算法进行加密，传输过程中的数据就是一串看起来乱码的数据，接收端使用非对称解密的算法进行解密，解密出原文。此时使用的是不同的算法，产生的密钥也不同，加密的密钥和解密的密钥互为一个密钥对，加密的称为公钥，解密的称为私钥。

1.3 场景

场景1

假设有两个服务serviceA和serviceB要进行通讯，不想让他人知道，直接使用一个socket发送了一个Hello过去，这显示是不行的，中间一旦被人截获，直接就拿到Hello这个数据了。

场景2

假设有两个服务serviceA和serviceB要进行通讯，A通过对称加密成一串密文发往B，但是网络是不安全的，很有可能被中间的人拿到密文，但是别人拿到密文，不知道是什么，也无法解开，查看不到原始数据，然后B收到了密文，但是B也不知道密钥是什么呀，怎么解开呢，或许我们可以先将密钥发送给B，再发送密文，这种方法也是不太可行，因为密钥在发送过程中也可能被其他人截获，那么再发送密文也不安全了。

场景3

那么我们考虑使用非对称加密的方法，AB之间生成密钥对，公开公钥，任何人都可以看到，黑客也可以看到，但是没关系，A通过这个公钥对数据进行加密传输给B，中间也可能被黑客截获，他只有公钥，无法解开，B接收到密文后通过自己的私钥解密，查看到了数据，此时数据是安全的。

通过非对称加密确实是把数据安全的送到了，但这里还隐藏了问题，就是非对称加密的算法非常复杂，运行这个算法不管是加密还是解密都对性能有非常大的损耗，如果每次通讯都进行非对称加密解密，性能损耗是无法接受的，相比于非对称加密，对称加密的性能非常高，试想，我们是否可以把两种算法结合在一起通讯呢？

场景4

首先A并不直接给B发送Hello，第一次通讯时使用非对称加密的公钥加密一个密钥，把密钥变成一个密文发到B，相当于把密钥安全的送到了B，B通过私钥可以把密文解开，解开后发现是一个对称加密的密钥，便会知道A要与他进行对称加密的通讯，并且使用的就是这个密钥，此时A使用发送给B的密钥加密后的Hello发送给B，并且B已经有了密钥，便可以解开，这种方式不管是性能还是安全性都得到了解决。

上面这个过程就是大家熟知的SSL/TLS协议，https底层就是通过这两个协议进行通讯的

1.4 CA

上面的场景4看起来很完美了，但还有一个潜在的风险，就是公钥在B返回给A的时候有可能会被黑客截获并替换成黑客自己的公钥，A拿着黑客的公钥加密数据传输后又被黑客截获了，那么黑客就可以使用自己的私钥把A要传输的数据解密出来了，数据就不安全了。为解决这个问题，就有了CA证书认证机构，就是一个中间商，是给所有人颁发证书的这样一个机构，所有正常的网站的证书都在这个地方存储，当A问B索要公钥拿到公钥后，他就要去CA查询这个公钥是否合法，一看这个公钥是存在的，是哪个公司的，他的域名是什么，包括所有人是谁，各种各样的信息在CA都有备案，CA告诉A这个公钥是我颁发的，那么A使用这个公钥就是安全的。

我们访问网页时https出现了红色感叹号或者红色划线，就说明他所使用的公钥不在CA的库中

二、Kubernetes认证方式

2.1 客户端证书认证（TLS双向认证）

kubectl通过Apiserver访问集群时，第一步就是要认证，Apiserver需要知道访问这个集群的是谁，这里使用的就是客户端证书认证，就叫做TLS双向认证，双向认证也就是kubectl在访问Apiserver时要验证这个Apiserver是否是合法的Apiserver，同样的，Apiserver也要验证这个客户端是否是合法的客户端。所以 Kubernetes需要一个CA，但是Kubernetes使用的CA并不是网站所使用的公有的CA，而是他自己的CA，在自定义的CA里面给每一个组件颁发证书。此时kubectl和Apiserver相互验证对方发送的公钥是否是合法的，验证通过后就可以通过认证的方式加密通讯了。

2.2 Bearer Token

这是个相对简单的认证方式，可以理解为有一个非常复杂的密码预先定义在Apiserver里面，他把密码告诉指定的客户端，然后这个客户端在跟Apiserver通讯时带上BearerToken给Apiserver验证，验证通过就可以进行通讯。

2.3 Service Account

前两种认证方式都是在集群外部通过认证就行访问的，Service Account 是为了方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的。

用户也可以创建自己的 User Account

Service Account 主要包含三个内容：

1. namespace命名空间
2. token密码
3. CA用于验证Apiserver的证书

这些信息都会通过目录挂载的方式挂载到这个Pod的文件系统里，应用就可以通过读取指定的文件去获取这些信息，拿到信息之后就可以跟Apiserver进行交互。

三、Kubernetes 授权

认证是第一关，认证只是知道你这个人身份没有问题，第二步就要知道你这个身份能够干哪些事情。

Kubernetes 有三种授权方式分别是ABAC、WebHook、RBAC；其中RBAC是1.6开始引入使用的，也是最新的一个授权策略，RBAC相对于其他两种机制是更好的选择，所以我们只需要学习RBAC。

RBAC全称Role Based Access Control译为基于角色的访问控制，每个系统都有一个结构，用户->角色->权限，具体三者之间的设计，因系统不同而不同，在 Kubernetes中，用户分为普通用户和ServiceAccount；权限根据资源类型（namespace、deployment、service…）和资源控制的方式（增删改查）两个维度进行区分；角色包含名字、权限、操作等信息。

在 Kubernetes中通过RoleBinding记录他们的对应关系。并且Role要放在namespace中，特定的Role只能拥有当前namespace下这个Role对应的权限。还有一种ClusterRole可以跨namespace操作，对应的有ClusterRoleBinding进行绑定。

四、准入控制（AdmisionControl）

最后一步是准入控制，准入控制可以理解为一个个小插件，一个个小代码，他们之间独立存在没有联系，我们的请求会经过准入控制的代码段里一个个执行一遍，具体执行的先后顺序会在配置Apiserver时指定，默认的AdmisionControl有十几二十种。