手动搭建kubernetes集群（三）

本文是这个系列的第三篇文章，前两篇记录了搭建一个k8s集群的过程，但是之前搭建好的集群少了很重要的一个部分，就是安全相关的功能，包括认证、授权等机制。 什么是认证，什么又是授权呢，可以简单的理解为，认证的目的是知道用户是谁，授权的目的是知道用户可以做什么。先认证，知道是谁，再授权知道能做什么。 所谓的安全，主要是针对apiserver所说的，因为k8s通过apiserver提供RESTFUL接口，所以如果有人知道你的apiserver地址，就可以修改你的集群信息了。 首先了解一下相关的基础知识，包括SSL、JWT、RBAC等等。

SSL介绍

SSL是一个协议，https中的s，代表的就是SSL。 网上关于SSL的介绍很多也很详细，我这里只说一下我的理解。为了保证网络传输过程中的安全，传输的信息需要进行加密处理。 加密可以分为两类，对称加密和非对称加密。

对称加密 所谓对称加密， 就是说加密和解密的方法是对称的，加密方怎么加密，解密方就怎么反过来解密。举个例子： Client端通过对称的加密算法md5以及一个秘钥，加密一段信息，并将加密后的信息通过请求发送给server端： secret = md5(key+info)

server端为了验证请求的来源合法性，采用同样的方式重新加密，并将结果和client端发来的加密结果对比，如果一致，就认为请求是合法的。 这个过程中，双方需要持有相同的key，并使用相同的加密方法。 2. 非对称加密 理解了对称加密，很容易想到，非对称加密就是双方的操作不一致。以常用的RSA加密来举例子： server端事先会生成一对key，一个可以公开的叫公钥，一个不能公开的叫私钥。公钥的内容任何人可见，但是只能用来加密，私钥用来解密（具体的原理请参考相关资料，基本思想就是质数分解）。所以上面的请求过程就变成了client端用server端给的公钥，把请求信息加密，然后发送给server，server端在收到请求后，用自己的私钥就可以解密从而获得请求信息。 3. 对比 使用对称加密的时候，双方都需要知道key，这就存在key被泄露的风险，而非对称加密则不存在这个问题，公钥谁都可以看，私钥不存在传输给别人的过程，安全程度大大加强。 但是非对称加密的问题是，运算速度比较慢，效率相对比较低。 4. SSL 说了这么多，终于回到SSL了，SSL大概就是结合了上面说的对称和非对称加密，利用了两者的优势，具体的操作大概是这样的： 非对称加密不是慢么？对称加密不是容易泄露key么？那好，用非对称的方式来传输对称加密使用的key，两个问题就都解决了。大致的工作流程如下：

client向server发起请求，拿到server端的公钥client用公钥把自己生成的key加密，然后发送给serverserver用私钥解密，获得了client的key两端可以愉快的用这个key通过对称加密的方式通信了。

当然实际的请求流程比我这个要复杂的多，各位自行了解吧~~

JWT介绍

JWT的全称是json web token，是一个标准，主要用于授权和信息交换。 看名字就知道，这货就是个token，具体来说，是一个由“.”分割的三个部分组成的字符串，这三个部分分别是：

headerplayloadsignature

看起来就是这样的aaaaaa.bbbb.cccc，这个字符串本身包含了一些信息，例如可以保存用户的ID等，这样服务端在接收到token之后，通过解密就直接拿到ID，不用再去数据库里查询了。token里同时还包括使用的签名算法等。具体的使用流程就是，server收到client请求的时候，用一个自己的secret使用某种加密算法生成一个这样的Token，然后发送给client，client获得token之后，每次请求都要在Authorization header里带上获得的token，header看起来是这样的：

Authorization: Bearer <token>

server端每次都会验证这个token是不是自己签发的那个有效的token，从而实现无状态http服务的状态，是不是感觉作用和session有些类似？其实还是有些差异的，比如： session存储在服务端，JWT存储在客户端。

RBAC介绍

RBAC的全称是Role-Based Access Control，基于角色的访问控制。 下面是我粗浅的理解： 把系统的操作权限拆分成一个个的小单位，多个小单位赋予某个角色，然后让用户属于某个角色，这样就可以灵活的控制用户对系统的访问控制了。还是举个例子： 某个管理后台里有很多功能，比如用户管理、订单管理、商品管理、用户留言管理，然后定义几个角色：超级管理员有所有权限，运营管理员有用户管理和留言管理权限，财务管理员有订单管理权限。ok，这样一个用户进来这个后台的时候，根据需要给他赋予某个角色，他就有了对应的管理权限，一个角色可以有多个用户，多个角色可以有相同的权限，也可以随时调整角色和权限的关系，非常灵活。不知道我说清楚了没有。具体的还请查阅相关文档。

kubernetes的认证和授权

认证 kubernetes支持三种方式的认证： HTTPS证书认证：基于CA根证书签名的双向数字证书认证方式，用到的就是前面说的SSL；HTTP Token认证：通过一个Token来识别合法用户，可以是普通token也可以是前面说过的JWT token；HTTP Base认证：通过用户名+密码的方式认证； apiserver支持设置一种或多种认证方式，如果设置了多种，那么通过其中任何一种，都认为是认证成功了。 授权 apiserver支持多种授权模式，例如Node,RBAC,Webhook等，可以在apiserver启动的时候指定授权模式，同样也可以指定一种或者多种，如果指定了多种，通过其中的某一种就认为是授权成功了，和认证类似。 客户端访问apiserver的时候，发起的http request中带有各种属性，例如user,group,path等，授权过程就是将这些属性与配置好的授权模式去比较，从而判断是否可以授权对应的操作。

总结

絮絮叨叨的总算写完了，说的再多，都不如撸起袖子加油干，接下来就在之前搭建好的基础版集群环境里去试验一下吧~~~