Kubernetes API Server 之集群安全认证

文章目录

• 前言

• 一、为什么要有 api-server 集群安全认证？

• 二、安全机制的三个流程

• 三、HTTP Bearer Token 认证

• 四、HTTPS 双向证书认证

• 总结

---

前言

        kubernetes API Server 是 kubernetes 集群的统一访问入口，它的核心功能就是提供 kubernetes 各类的资源对象（例如：Pod、Deployment、RC、Service 等）的增、删、改、查及 watch 等 HTTP REST 接口，成为集群中各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。并且它还是整个集群管理的 API 入口，资源配额控制的入口，提供了完整的安全机制。

一、为什么要有 api-server 集群安全认证？

        在 kubernetes 集群当中 kubernetes api server 为集群中所有内部服务访问的入口，也就是说，集群中的各个组件、pod、资源等都需要通过 kubernetes api server 来提供访问入口，在集群当中通过 kube-apiserver 来提供服务，因此 kubernetes api server 的安全性也就意味着集群的安全，其中包括 API Server 的认证、授权、准入控制以及保护敏感信息的 Secret 机制等。

二、安全机制的三个流程

        kubernetes 集群中所有的资源的访问和变更都是通过 kubernetes API Server 的 REST API 实现的，所以集群安全的关键点就在于如何识别并认证客户端身份（Authentication），以及随后访问权限的授权（Authorization）这两个关键问题，随后是准入控制（Admission）；

2.1、认证概述

        kubernetes 集群有两种账号：第一种是集群内部的 Service Account；第二种是外部的用户账号，可能是某运维人员或外部应用的账号。 kubernetes 并不支持常会的个人账号，但拥有被 kubernetes 集群的 CA 证书签名的有效证书，个人用户就可以被授权访问 kubernetes 集群了，在这种情况下，证书中的 Subject（主题）里的信息被当作用户名如 ”/CN=bob“ 。

2.2、kubernetes API Server 访问方式

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

三、HTTP Bearer Token 认证

3.1、访问认证流程：

        为了验证客户端访问者的身份，客户端需要向服务端提供一个可靠的身份信息，称之为 Token，这个 Token 被放在 HTTP Header 头里，在 Token 里有信息来表明客户身份，Token 通常是一个有一定长度的难以被篡改的字符串，用私钥签名一个字符串后的数据也可以被当作一个加密的 Token，在 kubernetes 中，每个Bearer Token 都对应一个用户名，存储在 API Server 能访问的一个文件中（Static Token file）。客户端发起 API 调用请求时，需要在 HTTP Header 里放入此 Token，这样一来 API Server 就能识别合法用户和非法用户了。

3.2、认证流程参数详解

        要使用 HTTP Bearer Token 认证就需要为 kubernetes API Server 设置一个保存用户信息和 Token 的文件，通过启动参数 ”--token-auth-file=/文件路径“ ，该文件为 CSV 文本文件格式，每行内容都由以下字段组成：

token：必填，Token字符串。

user：必填，用户名。

uid：必填，用户UD。

groupnames：用户组列表，如果有多个组，必须使用引号。

3.3、通过 Service Account 认证方式访问

        在默认情况下，kubernetes 集群中的 pod 想要访问 kube-apiserver 为了保证安全性就需要通过 SA 的认证加密， 该加密方式采用的是 Secret 存储机制来存储 HTTP Bearer Token 值，而想要访问 kube-apiserver 就需要使用该 token 值来进行认证，默认在 pod 创建之后会引用 Secret 存储卷来将 token 值以及需要认证的公钥信息等内容存储在容器中 /run/secrets/kubernetes.io/serviceaccount 目录下，这个 token 值是用那个私钥加密的呢？可以在 /etc/kubernetes/manifests/kube-apiserver.yaml 文件中查看 ”--service-account-key-file“ 参数指定的就是私钥文件路径，如果没有指定该文件则会采用 API Server 自己的私钥进行加密，如果设置启动参数 ”--service-account-lookup=ture“ 则 API Server 就会验证 Token 是否在 etcd 中存在，如果已从 etcd 中删除，则将注销容器中 Token 的有效性。

四、HTTPS 双向证书认证

4.1、为什么使用 HTTPS 双向认证方式？

         在 kubernetes 集群当中，其它认证方式（Bearer Token、HTTP Base）都是单项认证，所谓单项认证就是服务器验证客户端，而客户端并没有认证服务端，此时就会出现一个问题，就是客户端并不知道对方是不是我要访问的目标服务端的 kubernetes API Server，为了避免此问题则可以使用 HTTPS 双向认证的方式。

4.2、HTTPS 双向认证流程

        1、首先客户端和服务端都向 CA 机构去申请证书，而 CA 则是系统中通信双方都信任的实体，被成为可信第三方（Trusted Third Party，TTP）。CA 做为可信的第三方，其保证了证书的安全可用性，如果证书出现问题，则 CA 证书第三方会承担相应责任；CA 收到申请之后会向服务端和客户端下发证书（包括：根证书、服务端/客户端证书、私钥），其中如果是服务端申请则下发服务端证书，客户端申请则下发客户端证书。

        2、双方都收到证书之后客户端会向服务端发送下发证书的请求，服务端收到请求之后会向客户端下发服务端证书到客户端，客户端收到服务端下发的证书之后会使用根证书来验证服务端发送过来的证书合法性（确定服务端身份）。

        3、验证无误之后客户端会向服务端发送客户端证书给服务端，服务端收到客户端发送过来的证书之后会使用根证书来验证客户端证书的合法性（确定客户端身份）。

        4、在客户端和服务端相互认证并协商好加密方案之后，客户端会产生一个随机密钥，客户端则通过于服务端协商好的加密方案去加密该随机密钥，并将加密之后的密钥发送至服务端，服务端接收到该密钥之后双方通信的内容都通过该随机密钥进行加密。

kubeconfig 目录：

        该目录下存放着含集群参数（CA证书、API Server地址），客户端参数（上面生成的证书和私钥），集群 context 信息（集群名称、用户名）。Kubenetes 组件通过启动时指定不同的 kubeconfig 文件可以切换到不同的集群。

4.3、kubernetes 各组件加密的安全等级

        如下图，kubernetes 中各个组件（kube-Scheduler、kube-Controller-Manager、ETCD、kubelet、kube-proxy、kubectl）都需要和 kube-apiServer 进行交互访问，而此时就涉及到了集群访问的安全性，而 kube-apiServer 是在 Master 节点上运行的，而要进行认证的安全等级也不相同，比如 kube-Scheduler、kube-Controller-Manager、ETCD 等组件和 kube-apiServer 是在同一个节点上，这时它们之间认证的等级就相对较低，因为是在同一个节点当中运行，所以可以使用非安全加密端口进行交互访问，如果在同一个节点设置加密认证访问则大大消耗了集群的资源，每次访问都需要进行认证，而另外一种情况就是在其它节点向 master 节点进行访问，比如 node 节点的 kubelet 组件，向 Master 节点的 kube-apiServer 访问时就需要进行 HTTPS 双向的加密认证访问，提高安全性。

---

总结

        本次文章主要针对 kubernetes 集群中的安全认证机制进行了简单的讲解说明，集群当中的安全无论是对公司业务还是集群信息安全性来说都是至关重要的，通过加密认证的方式来确保客户端以及 kubernetes 各个组件之间的通信是安全可靠的，之后会更新 kubernetes 鉴权机制的讲解文档。