理清 Kubernetes 中的准入控制（Admission Controller）

大家好，我是张晋涛。

在我之前发布的文章 《云原生时代下的容器镜像安全》（系列）中，我提到过 Kubernetes 集群的核心组件 --  kube-apiserver，它允许来自终端用户或集群的各组件与之进行通信（例如，查询、创建、修改或删除 Kubernetes 资源）。

本篇我们将聚焦于 kube-apiserver 请求处理过程中一个很重要的部分 -- 准入控制器（Admission Controller）

K8s 的准入控制器是什么

K8s 中的请求处理流程

在聊 K8s 准入控制器是什么之前，让我们先来回顾一下 Kubernetes API 的处理具体请求的过程。

img

图 1 ，Kubernetes API 处理请求的过程 （从 API Handler 到 etcd 持久化的过程）

如上图所示，每个 API 的请求从开始被 kube-apiserver 接收到最终持久化到 ETCD 的过程，即为 Kubernetes API 的请求处理流程。

它主要包含了以下几个部分：

• API Handler -- 主要负责提供服务，接收请求。

对于其内部实现而言，请求会先到 FullHandlerChain （它是由 DefaultBuildHandlerChain 构建出来的）是一个 director 对象

type director struct {
 name               string
 goRestfulContainer *restful.Container
 nonGoRestfulMux    *mux.PathRecorderMux
}

director根据配置进行初始化，如果 goRestfulContainer的 WebServices 的 RootPath 是 /apis，或者请求前缀与 RootPath 匹配，则进入 Restful 处理链路。

• Authentication -- 认证的流程。

在TLS 连接建立后，会进行认证处理，如果请求认证失败，会拒绝该请求并返回 401 错误码；如果认证成功，将进行到鉴权的部分。目前支持的客户端认证方式有很多，例如：x509 客户端证书、Bearer Token、基于用户名密码的认证、OpenID 认证等。由于这些内容不是本篇的重点我们暂且跳过，感兴趣的小伙伴可以在评论区留言讨论。

• Authorization -- 鉴权的流程。

对于 Kubernetes 而言，支持多种的鉴权模式，例如，ABAC 模式，RBAC 模式和 Webhook 模式等。我们在创建集群时，可以直接为 kube-apiserver 传递参数进行配置，这里也不赘述了。

• Mutating Admission -- 指执行可用于变更操作的准入控制器，下文中会详细介绍。

• Object Schema Validation -- 对资源对象的 schema 校验。

• Validating Admission -- 指执行可用于验证操作的准入控制器，下文中会详细介绍。

• ETCD -- ETCD 实现资源的持久化存储。

上面便是一个请求的处理流程，其中 Mutating Admission 和 Validating Admission 便是我们今天的主角。我们来详细的看一看。

什么是准入控制器（Admission Controller）

准入控制器是指在请求通过认证和授权之后，可用于对其进行变更操作或验证操作的一些代码或功能。

准入控制的过程分为两个阶段：

• 第一阶段，运行变更准入控制器（Mutating Admission）。它可以修改被它接受的对象，这就引出了它的另一个作用，将相关资源作为请求处理的一部分进行变更；

• 第二阶段，运行验证准入控制器（Val