Kubernetes 组件的认证方式

在 Kubernetes 中包含多个以独立进程形式运行的组件，这些组件之间通过 HTTP/gRPC 相互通信，以协同完成集群中应用的部署和管理工作。

从图中可以看到，Kubernetes 控制平面中包含了 etcd，kube-api-server，kube-scheduler，kube-controller-manager 等组件，这些组件会相互进行远程调用，例如 kube-api-server 会调用 etcd 接口存储数据，kube-controller-manager 会调用 kube-api-server 接口查询集群中的对象状态；同时，kube-api-server 也会和在工作节点上的 kubelet 和 kube-proxy 进行通信，以在工作节点上部署和管理应用。

以上这些组件之间的相互调用都是通过网络进行的。在进行网络通信时，通信双方需要验证对方的身份，以避免恶意第三方伪造身份窃取信息或者对系统进行攻击。为了相互验证对方的身份，通信双方中的任何一方都需要做下面两件事情：

向对方提供标明自己身份的一个证书
验证对方提供的身份证书是否合法，是否伪造的？

在 Kubernetes 的组件之间进行通信时，数字证书的验证是在协议层面通过 TLS 完成的，除了需要在建立通信时提供相关的证书和密钥外，在应用层面并不需要进行特殊处理。采用 TLS 进行验证有两种方式：

服务器单向认证：只需要服务器端提供证书，客户端通过服务器端证书验证服务的身份，但服务器并不验证客户端的身份。这种情况一般适用于对 Internet 开放的服务，例如搜索引擎网站，任何客户端都可以连接到服务器上进行访问，但客户端需要验证服务器的身份，以避免连接到伪造的恶意服务器。
双向 TLS 认证：除了客户端需要验证服务器的证书，服务器也要通过客户端证书验证客户端的身份。这种情况下服务器提供的是敏感信息，只允许特定身份的客户端访问。

在 Kubernetes 中，各个组件提供的接口中包含了集群的内部信息。如果这些接口被非法访问，将影响集群的安全，因此组件之间的通信需要采用双向 TLS 认证。即客户端和服务器端都需要验证对方的身份信息。在两个组件进行双向认证时，会涉及到下面这些证书相关的文件：

服务器端证书：服务器用于证明自身身份的数字证书，里面主要包含了服务器端的公钥以及服务器的身份信息。
服务器端私钥：服务器端证书中包含的公钥所对应的私钥。公钥和私钥是成对使用的，在进行 TLS 验证时，服务器使用该私钥来向客户端证明自己是服务器端证书的拥有者。
客户端证书：客户端用于证明自身身份的数字证书，里面主要包含了客户端的公钥以及客户端的身份信息。
客户端私钥：客户端证书中包含的公钥所对应的私钥，同理，客户端使用该私钥来向服务器端证明自己是客户端证书的拥有者。
服务器端 CA 根证书：签发服务器端证书的 CA 根证书，客户端使用该 CA 根证书来验证服务器端证书的合法性。
客户端 CA 根证书：签发客户端证书的 CA 根证书，服务器端使用该 CA 根证书来验证客户端证书的合法性。

Kubernetes 中使用到的CA和证书

下图标识出了在 kubernetes 中主要使用到的证书和其使用的位置：

Kubernetes 中使用到的主要证书

上图中使用序号对证书进行了标注。图中的箭头表明了组件的调用方向，箭头所指方向为服务提供方，另一头为服务调用方。为了实现 TLS 双向认证，服务提供方需要使用一个服务器证书，服务调用方则需要提供一个客户端证书，并且双方都需要使用一个 CA 证书来验证对方提供的证书。为了简明起见，上图中只标注了证书使用方提供的证书，并没有标注证书的验证方验证使用的 CA 证书。图中标注的这些证书的作用分别如下：

etcd 集群中各个节点之间相互通信使用的证书。由于一个 etcd 节点既为其他节点提供服务，又需要作为客户端访问其他节点，因此该证书同时用作服务器证书和客户端证书。
etcd 集群向外提供服务使用的证书。该证书是服务器证书。
kube-apiserver 作为客户端访问 etcd 使用的证书。该证书是客户端证书。
kube-apiserver 对外提供服务使用的证书。该证书是服务器证书。
kube-controller-manager 作为客户端访问 kube-apiserver 使用的证书，该证书是客户端证书。
kube-scheduler 作为客户端访问 kube-apiserver 使用的证书，该证书是客户端证书。
kube-proxy 作为客户端访问 kube-apiserver 使用的证书，该证书是客户端证书。
kubelet 作为客户端访问 kube-apiserver 使用的证书，该证书是客户端证书。
管理员用户通过 kubectl 访问 kube-apiserver 使用的证书，该证书是客户端证书。
kubelet 对外提供服务使用的证书。该证书是服务器证书。
kube-apiserver 作为客户端访问 kubelet 采用的证书。该证书是客户端证书。
kube-controller-manager 用于生成和验证 service-account token 的证书。该证书并不会像其他证书一样用于身份认证，而是将证书中的公钥/私钥对用于 service account token 的生成和验证。kube-controller-manager 会用该证书的私钥来生成 service account token，然后以 secret 的方式加载到 pod 中。pod 中的应用可以使用该 token 来访问 kube-apiserver， kube-apiserver 会使用该证书中的公钥来验证请求中的 token。我们将在文中稍后部分详细介绍该证书的使用方法。

通过这张图，对证书机制比较了解的读者可能已经看出，我们其实可以使用多个不同的 CA 来颁发这些证书。只要在通信的组件中正确配置用于验证对方证书的 CA 根证书，就可以使用不同的 CA 来颁发不同用途的证书。但我们一般建议采用统一的 CA 来颁发 kubernetes 集群中的所有证书，这是因为采用一个集群根 CA 的方式比采用多个 CA 的方式更容易管理，可以避免多个CA 导致的复杂的证书配置、更新等问题，减少由于证书配置错误导致的集群故障。

API 请求访问控制

Kubernetes 集群在多租户环境下必须要采取的一个基本的安全架构手段。

在概念上可以抽象的定义为谁在何种条件下可以对什么资源（Pod、 ConfigMaps、Deployment、Secrets 等等这样的资源模型）做什么操作。

Kubernetes API 的请求从发起到其持久化入库的一个流程

请求的发起分为两个部分

kubectl 对 api-server 的一个请求过程
Pod 中的业务逻辑与 api-server 之间的交互。

api-server 收到请求后，就会开启访问控制流程。这里面分为三个步骤

Authentication 认证阶段：判断请求用户是否为能够访问集群的合法用户。如果用户是个非法用户，那 api-server 会返回一个 401 的状态码，并终止该请求
如果用户合法的话，我们的 api-server 会进入到访问控制的第二阶段 Authorization：鉴权阶段。在该阶段中 api-server 会判断用户是否有权限进行请求中的操作。如果无权进行操作，api-server 会返回 403 的状态码，并同样终止该请求
如果用户有权进行该操作的话，访问控制会进入到第三个阶段：AdmissionControl。在该阶段中 api-server 的 Admission Control 会判断请求是否是一个安全合规的请求。如果最终验证通过的话，访问控制流程才会结束。

此时我们的请求将会转换为一个 Kubernetes objects 相应的变更请求，最终持久化到 ETCD 中。

Kubernetes 认证

Kubernetes 中的用户模型

Kubernetes 没有自身的用户管理能力，无法像操作 Pod 一样，通过 API 的方式创建删除一个用户实例。同时我们也无法在 ETCD 中找到用户对应的存储对象。
Kubernetes 中的用户通常是通过请求凭证设置
- 访问控制流程中用户模型就在请求方的访问控制凭证中，也就是我们平时使用的 kube-config 中的证书，或者是 Pod 中引入的 ServerAccount。
- 经过 Kubernetes 认证流程之后，api-server 会将请求中凭证中的用户身份转化为对应的 User 和 Groups 这样的用户模型。在随后的鉴权操作和审计操作流程中，api-server 都会使用到改用户模型实例。
请求认证方式主要包括
- Basic 认证
  
  管理员会将 Username 和 Password 组成的白名单放置在 api-server 读取的静态配置文件上面进行认证，该方式一般用于测试场景，在安全方面是不推荐且不可拓展的一种方式。
- X509 证书认证
  
  该方式是 api-server 中相对应用较多的使用方式，首先访问者会使用由集群 CA 签发的，或是添加在 api-server Client CA 中授信 CA 签发的客户端证书去访问 api-server。api-server 服务端在接收到请求后，会进行 TLS 的握手流程。除了验证证书的合法性，api-server 还会校验客户端证书的请求源地址等信息。开启双向认证，X509 认证是一个比较安全的方式，也是 Kubernetes 组件之间默认使用的认证方式，同时也是 kubectl 客户端对应的 kube-config 中经常使用到的访问凭证。
- Bearer Tokens(JSON Web Tokens)
  
  该方式的 Tokens 是通用的 JWT 的形式，其中包含了签发者、用户的身份、过期时间等多种元信息。它的认证方式也是常见的私钥加签，公钥验签的一个基本流程。基于 Token 的认证使用场景也很广泛，比如 Kubernetes Pod 应用中经常使用到的 Service Account，其中就会自动绑定一个签名后的 JWT Token 用于请求 api-server。
  
  支持Service Account，OpenID Connect，Webhooks（将请求的 Token 发送到指定外部服务进行 Token 的验签）

X509

对于一个集群证书体系来说，认证机构 (CA) 是一个非常重要的证书对。它会被默认放置在集群 Master 节点上的 /etc/kubernetes/pki/ 目录下。集群中所有组件之间的通讯用到的证书，其实都是由集群根 CA 来签发的。在证书中有两个身份凭证相关的重要字段：一个是 CN（user），一个是 O(group)。

上面每一个组件证书都有自己指定的 Common Name 和 Organization 用于特定角色的绑定。这样的设置可以使各系统组件只绑定自身功能范围内的角色权限。从而保证了每个系统组件自身权限的最小化。

使用证书的组件如下：

etcd：使用 ca.pem、kubernetes-key.pem、kubernetes.pem；
kube-apiserver：使用 ca.pem、kubernetes-key.pem、kubernetes.pem；
kubelet：使用 ca.pem；
kube-proxy：使用 ca.pem、kube-proxy-key.pem、kube-proxy.pem；
kubectl：使用 ca.pem、admin-key.pem、admin.pem；
kube-controller-manager：使用 ca-key.pem、ca.pem

证书签发 API 生成 kubeconfig

获得 crt

Kubernetes 集群本身就提供了证书签发的 API，而在集群的创建过程中，像 kube-admin 这样的集群安装工具，会基于不同的 CSR 签发请求调用 api-server 对应接口。此时 api-server 会根据请求，以这种 csr 资源模型的形式创建对应的签发请求实例。刚开始创建的签发实例都会处于 pending 的状态，直到有权限的管理员进行审批后，这个 csr 才会处于 approved 的状态，请求对应的证书就会被签发。

开发人员需用通过 openssl 等证书工具生成私钥，然后创建对应的 X509 csr 请求文件
在 sbuj 字段中指定用户 user 和组 group，最后通过 API 创建 K8s csr 实例并等待管理员审批。
集群管理员可以通过kubectl api签发，也可以通过openssl签发得到 crt 文件给开发人员

获得kubeconfig

使用kubeconfig , 通过context name切换

# 不能有重复name
KUBECONFIG=~/.kube/this-config:~/.kube/other-config kubectl config view --flatten > ~/.kube/config

Service Accounts

除了证书认证之外，Service Account 也是 api-server 中应用比较广泛的一种方式。对于 Service Account 来说，它是 k8s中唯一能够通过 API 方式管理的 APIService 访问凭证，其他特性在上图中可以看到。

图中也给出了一些使用 kubectl 进行 Service Account API 相关增删改查的示例，同时我们也为已经存在的 Service Account 主动的创建其 Token 对应的 Secret，有兴趣的同学可以在 Kubernetes 集群中操作执行一下。

首先可以通过 get secrets 命令查看对应 Service Account 中对应的 secret，其中 token 字段经过了 base64 位编码的 JWT 格式认证 token。

在部署一个应用时，可以通过 Template-spec-serviceAccountName 字段声明需要使用的 Service Account 名称。注意如果是在 Pod 创建过程中，发现制定的 ServiceAccount 不存在，则该 Pod 创建过程会被终止。

在生成的 Pod 模板中可以看到指定 Service Account 对应的 secret 中的 CA namespace 和认证 token 会分别以文件的形式挂载到容器中的指定目录下，另外对于已经创建的 Pod，我们不能更新其已经挂载的 ServiceAccount 内容。

Kubernetes 鉴权 - RBAC

通过Kubernetes 鉴权，可以认为它是一个合法的用户，那么如何控制该用户在集群中的哪些 namespace 中访问哪些资源，对这些资源又能进行哪些操作呢

第一要素是 Subjects，也就是主体。可以是开发人员、集群管理员这样的自然人，也可以是系统组件进程，或者是 Pod 中的逻辑进程；
第二个要素是 API Resource，也就是请求对应的访问目标。在 Kubernetes 集群中也就是各类资源；
第三要素是 Verbs，对应为请求对象资源可以进行哪些操作，包括增删改查、list、get、watch 等。

权限粒度

角色绑定到一个具体的控制域内。这就是 Kubernetes 大家熟悉的命名空间。通过 namespace 可以将 Kubernetes api 资源限定在不同的作用域内。从而帮助我们在一个多租户集群中，对用户进行逻辑上的隔离。

这里需要注意的是，如果不进行任何的权限绑定，RBAC 会拒绝所有访问。

通常 RBAC 会进行对 api-server 的细粒度访问控制，但是这个细粒度是个相对的概念，RBAC 是面向模型级别的绑定。它不能绑定到 namespace 中的一个具体的 object 实例，更不能绑定到指定资源的任意一个 field。

RBAC 对访问权限的控制粒度上，它可以细化到 Kubernetes api 的 subresources 级别。比如针对一个访问者，我们可以控制其在指定 namespace 下对 nodes/status 模型的访问。

Role

首先是角色 Role，它定义了用户在指定的 Kubernetes 命名空间资源上可以进行哪些操作。比如可以定一个 namespace 中 pod 的只读权限，同时还可以定义一个 namespace 管理员权限，它具有对这个命名空间下所有对象资源的所有操作权限。

如上图所示，是一个 Role 的定义模板编排文件，其中 resource 字段定义了这个角色可以访问哪些资源，verbs 字段定义了这个角色有哪些操作的权限。在 apiGroups 中，需要指定目标资源的 apiGroups 名称，这里可以通过官方 API 文档查询，如果指定的 Group 是 core，那么在角色模板中的 apiGroups 可置为空。

RoleBinding

当我们完成了一个 namespace 下的角色定义之后，还需要建立其与使用这个角色的主体之间在 namespace 下的绑定关系，这里需要一个 RoleBinding 模型。使用 RoleBinding 可以将 Role 对应的权限模型绑定到对应的 Subject 上。

比如这里可以将名为 test 的 namespace 中的 pod 只读权限同时绑定给用户 test1 和 test2 以及 proc1。也可以将 namespace test 只读权限绑定组名称为 tech-lead 的 test1 用户，这样用户 test2 和 proc1 是没有 get namespace 权限的。

接着看一下对应的 RoleBinding 编排文件模板。

其中 roleRef 字段中声明了我们需要绑定的角色，一个绑定只能指定唯一的 Role。在 subject 字段中定义了我们要绑定的对象，这里可以是 User，Group 或者是 Service Account。它同时支持绑定多个对象。

ClusterRole

除了定义指定 namespace 中的权限模型，也可以通过 ClusterRole 定义一个集群维度的权限模型。在一个 Cluster 实例中，可以定义集群维度的权限使用权限，比如像 PV、Nodes 在 namespace 中不可见的资源权限，可以在 ClusterRole 中定义，而操作这些资源的动作同样是之前 Role 中支持的增删改查和 list、watch 等操作。