身份认证和权限控制

这次在读《kubernetes权威指南》时，看到第六章对身份认证和权限控制这部分的内容。自己平时虽然一直都在使用这两个功能，但理解的最觉得很片段。这里将原理整体介绍了（自己感觉的），在此做以摘抄。

我们都知道，Kubernetes 集群中所有的资源访问和变更都是通过 Kubernetes API Server 的 REST API 来实现的，所以集群安全的关键点就在于如何识别并认证（Authentication）客户端身份，以及随后的访问权限的授权（Authorization）这两个关键的问题，本节对认证管理进行说明。

我们知道，Kubernetes 提供了三种级别的客户端认证方式。

1. 最严格的 HTTPS 证书认证：基于 CA 根证书签名的双向数字证书认证方式。
2. HTTP Token 认证：通过一个 Token 来识别合法用户。
3. HTTP Base 认证：通过 用户名+密码的方式认证。

一般的服务程序所使用的用户身份认证方式也应该在上述三种方式中。

HTTPS 证书认证的原理。

（这是我一直想知道的，但却总是忘了查）

这里需要一个 CA 证书，我们知道 CA 是PKI 系统中通信双方都信任的实体，被称为可信第三方（Trusted Third Party，TTP）。CA 所谓可信第三方的重要条件之一就是 CA 的行为具有非否认性。作为第三方而不是简单的上级，就必须能让信任者有追究自己责任的能力。CA 通过证书证实他人的公钥信息，证书上有 CA 的签名。用户如果因为信任证书而有了损失，则证书可以所谓有效的证据用于追究 CA 的法律责任。正式因为 CA 承担责任的承诺，所以 CA 也被称为可信第三方。CA 与用户是相互独立的实体，CA 作为服务提供方，有可能应为服务质量问题（例如：发布的公钥信息有错误）给用户带来损失。在证书中绑定了公钥数据和相应私钥拥有者的身份信息，并带有 CA 的数字签名；在证书中也包含了 CA 的名称，以便依赖方找到 CA 的公钥，验证证书上的数字签名。

这块是自己理解的：
CA 是个身份信息鉴定机构，用户（客户端或者服务器）将自己的身份信息写成公钥交给 CA 去鉴定，如果 CA 鉴定身份属实后会给用颁发一张证书，这张证书里有：公钥、私钥拥有者的身份信息、数字签名。数字签名就相当于 CA 往证书的右下角盖了一个红戳，用于向其他用户表明，这张证书上的公钥信息和私钥信息是我这个CA 鉴定的，我担保这些信息是正确的、安全的、可信的，你们（其他用户）如果因为相信这张证书而被骗了，我这个 CA 负责赔偿损失，并承担法律责任。

CA 认证涉及诸多概念，比如根证书、自签名证书、**、私钥、加密算法及 HTTPS 协议等，本书大致讲述 SSL 协议流程，有助于理解 CA 认证和 Kubernetes CA 认证的配置过程。

1. HTTPS 通信双方的服务器端向 CA 机构申请证书，CA 机构是可信任的第三方机构，它可以是一个公认的权威企业，也可以是企业自身。企业内部系统一般用企业自身的认证系统。CA 机构下发根证书、服务端证书以及私钥给申请者。
2. HTTPS 通信双方的客户端向 CA 机构申请证书，CA 机构下发根证书、客户端证书以及私钥给申请者。
3. 客户端向服务器发起请求，服务端下发服务端证书给客户端。客户端接收到证书后，通过私钥解密证书，并利用好服务器端证书中的公钥认证证书信息比较证书里的消息（这块比较拗口，我的理解是：CA 颁发给服务器的根证书和 服务器下发给客户端的证书不是同一个东西，根证书是服务端证书的一部分。换句话说就是：服务器在根证书的基础上又添加了一些服务器的相关信息，构成了服务端证书，最后下发给了客户端），例如：比较域名和公钥与服务器刚刚发送的消息是否一致。如果一致，则客户端认可这个服务器的合法身份。
4. 客户端发送客户端证书给服务器端，服务器端在接收到证书后，通过私钥解密证书，获取客户端证书公钥，并用该公钥认证（客户端）证书信息，确认客户端身份是否合法。
5. 客户端通过随机**加密信息，并发送加密后的信息给服务端。在服务端和客户端商量好加密方案后，客户端会产生一个随机的**，客户端通过协商好的加密方案加密该随机**，并发送该随机**到服务器端。服务器端接收到这个**后，双方通信全部内容都会通过该**加密。（这个应该是对称加密的过程，也就是说在执行完第4步后，服务器与客户端都已经确认对方的身份了，第5步开始执行传输数据前的对称加密过程）

上述是双向认证SSL协议的具体通信过程，这种情况要求服务器和客户端都要有证书。单向认证SSL协议则不需要客户端拥有CA证书。在上述的步骤中只需要将服务器验证客户端证书的步骤去掉，之后协商对称密码方案和对称通话**时，服务器发送给客户的密码没被加密即可。

HTTP Token 认证原理

HTTP Token 的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串----Token 来表明用户身份的一种方式。在通常情况下，Token 是一个很复杂的字符串，比如我们用私钥签名一个字符串后的数据就可以被当做一个 Token。此外每一个Token 对应一个用户名，存储在 API-server 能访问的一个文件中。当客户端发起 API 调用请求时，需要再 HTTP Header 里放入 Token，这样一来，API-server 就能识别合法用户与非法用户了。（如果是 web服务端程序，Token应该是存放在浏览器的 Cookie中吧）。

HTTP Base 认证

我们都知道 HTTP 是无状态的，浏览器和 Web服务器可以之前可以通过 Cookie 来进行身份识别。桌面应用程序（新浪桌面客户端、命令行程序）一般不会使用 Cookie，那他们与 Web服务器之间是如何进行身份识别呢？这就用到了 HTTP Base 认证，这种认证方式是把“用户名+冒号+密码”用 BASE64 算法进行编码后的字符串放在 request 中的 Header Authentication 域里发送给服务端，服务端在收到后进行解码，获取用户名及密码，然后进行身份鉴权。