34 K8S 之 ServiceAccount 及 X509 数字证书

Kubernetes 原生的应用程序意味着专为运行于 Kubernetes 系统之上而开发的应用程序，这些程序托管运行在 Kubernetes 之上，能够直接与 API Server 进行交互，并进行资源状态的查询或更新，例如 Flannel 和 CoreDNS 等。显然，API Server 同样需要对这类来自 Pod 资源中的客户端程序进行身份验证，服务账户也是专用于这类场景的账号。ServiceAccount 资源一般由用户身份信息及保存了认证信息的 Secret 对象组成。

Kubernetes 系统通过 3 个独立的组件间相互协作实现了上面描述的 Pod 对象服务账户的自动化过程：ServiceAccount 准入控制器、令牌控制器和 ServiceAccount 控制器。ServiceAccount 控制器负责为名称空间管理相应的资源对象，它需要确保每个名称空间中都存在一个名为 default 的服务账户对象。ServiceAccount 准入控制器内置在 API Server 中，负责在创建或更新 Pod 时按需进行 ServiceAccount 资源对象相关信息的修改。

一个 ServiceAccount 资源可由其所属名称空间中的多个 Pod 对象共享使用。创建 Pod 资源时，用户可使用 spec.serviceAccountName 属性直接指定要使用的 ServiceAccount 对象，或者省略此字段而由准入控制器自动附加当前名称空间中默认的 ServiceAccount，以确保每个 Pod 对象至少基于该服务账户有权限读取当前名称空间中其他资源对象的元数据信息。

X509 数字证书认证常用的方式有“单向认证”和“双向认证”。SSL / TLS 最常见的应用场景是将 X.509 数字证书与服务器端关联，但客户端不使用证书。单向认证是客户端能够验证服务端的身份，但服务端无法验证客户端的身份，至少不能通过 SSL / TLS 协议进行。之所以如此，是因为 SSL / TLS 安全性最初是为互联网应用开发，保护客户端是高优先级的需求，它可以让客户端确保目标服务器不会被冒名顶替。

Kubernetes 集群中存在 3 个需要独立完成 X509 数字证书认证和 HTTPS 通信的体系：一是 etcd 集群成员、服务器及其客户端；二是 API Server 及其客户端，以及 kubelet API 及其客户端；三是 Kubernetes 认证代理体系中的服务器和客户端。这 3 个独立的体系各自需要一个独立证书颁发机构为体系内的服务器和客户端颁发证书，完成体系内的组件身份认证同时又彼此隔离。

Kubernetes 集群各组件中，kube-apiserver 是唯一一个可直接与集群存储通信的组件，它是 etcd 服务的客户端。

对于大型组织来说，Kubernetes 系统用户量大且变动频繁，静态密码文件和静态令牌文件认证方式动辄需要重启 API Server，而 X509 认证中的证书维护开销较高且无法灵活变动凭据生效期限，因此这些认证方式都非理想选择。实践中，人们通常使用 ID Token 进行 Kubernetes 的普通用户身份认证，API Server 的 OpenIDConnect 令牌认证插件即用于该场景。

Kubernetes 采用了由 kubelet 自行生成私钥和证书签署请求，而后发送给集群上的证书签署进程（CA），由管理员审核后予以签署或直接由控制器进程自动统一签署。这种方式就是 kubelet TLS Bootstrapping 机制。