K8s-集群安装认证

API Server认证

三大K8s API访问模式：

以Service Account方式访问K8s的内部服务进程
以匿名方式访问的进程
以证书方式访问的普通用户或进程，包括运维人员及kubectl、 kubelets等进程

K8s的用户认证方式：

HTTPS证书认证：基于CA根证书前面的双向数字证书认证方式
HTTP Bearer Token认证：通过一个Bearer Token识别合法用户
OpenID Connect Token第三方认证：通过第三方OIDC协议进行认证
Webhook Token认证：通过外部Webhook服务进行认证
Authenticating Proxy认证：通过认证代理程序进行认证

HTTPS证书认证

这里需要有一个CA证书，CA是PKI系统中通信双方都信任的实体，被称为可信第三方（Trusted Third Party，TTP）。CA作为可信第三方的重要条件之一，就是其行为具有非否认性。作为第三方而不是简单的上级，就必须让信任者有追究自己责任的能力。CA通过证书证实他人的公钥信息，在证书上有CA的签名。如果用户因为信任证书而有了损失，证书就可以作为有效的证据用于追究CA的法律责任。CA正是因为对责任的承诺，也被称为可信第三方。

CA的工作流程：

HTTPS通信双方的服务端向CA机构申请证书，CA机构是可信的第三方机构，它可以是一个公认的权威企业，也可以是企业自身。企业内部系统一般都用企业自身的认证系统。CA机构下发根证书、服务端证书及私钥给申请者。
HTTPS通信双方的客户端向CA机构申请证书，CA机构下发根证书、客户端证书及私钥给申请者。
客户端向服务端发起请求，服务端下发服务端证书给客户端。客户端在接收到证书后，通过私钥解密证书，并利用服务端证书中的公钥认证证书信息比较证书里的消息，例如，比较域名和公钥与服务器刚刚发送的相关消息是否一致，如果一致，则客户端认可这个服务器的合法身份
客户端发送客户端证书给服务端，服务端在接收到证书后通过私钥解密证书，获得客户端证书公钥，并用该公钥认证证书的信息，确认客户端是否合法
客户端通过随机密钥加密信息，并发送加密后的信息给服务端。在服务端和客户端协商好加密方案后，客户端会产生一个随机的密钥，客户端通过协商好的加密方案加密该随机密钥，并发送该随机密钥到服务端。服务端接收这个密钥后，双方通信的所有内容都通过该随机密钥加密

HTTP Bearer Token认证

通过Service Account认证方式访问API Server，其实也采用了与 HTTP Bearer Token相同的实现方式。我们知道，每个Service Account都对应一个Secret对象，在Secret对象中就有一个加密的Token字段，这个 Token字段就是Bearer Token。

另外，如果API Server设置了启动参数–service-account-lookup=true，API Server就会验证Token是否在 etcd中存在，如果已从etcd中删除，则将注销容器中Token的有效性

OpenID Connect Token第三方认证

Kubernetes也支持使用OpenID Connect协议（简称OIDC）进行身份认证。OIDC协议是基于OAuth 2.0协议的身份认证标准协议，在OAuth 2.0上构建了一个身份层，OIDC的登录过程与OAuth相比，最主要的扩展就是提供了ID Token，这是一个JWT格式的加密Token。API Server本身与OIDC Server（即Identity Provider）没有太多交互，用户（主要是 kubectl用户）通过OIDC Server得到一个合法的ID Token，并作为命令行参数（或者kubectl的配置文件）传递给API Server，API Server则通过验证该Token是否合法及是否有效来确定用户的身份。虽然在OIDC Server 中可以做到用户的权限管理，但Kubernetes并不使用OIDC Server的权限管理，因为它有自己完善的BRAC权限管理体系

Authenticating Proxy

在这种方式下，将API Server配置为从HTTP Header（例如XRemote-User字段）对用户进行识别。这需要与Authenticating Proxy程序一同工作，由Authenticating Proxy设置HTTP Header的值。

Service Account

Service Account也是一种账号，但它并不是给Kubernetes集群的用户（系统管理员、运维人员、租户用户等）用的，而是给运行在Pod里的进程用的，它为Pod里的进程提供了必要的身份证明。