Kubernetes安全强化：深入解析AdmissionConfiguration和ImagePolicyWebhook 🛡️

10 月 25, 2026

—

cslab

in IT Security

大家好！为了正在探索Kubernetes世界的各位，今天我将详细而简单地解释两个强大的工具，它们可以进一步提升集群的安全性和稳定性：AdmissionConfiguration和ImagePolicyWebhook。

🚀 前言：为什么需要这些？

在Kubernetes集群中，您可以使用kubectl apply等命令非常轻松地部署应用程序。这确实很方便！但在这里，我们需要提出一个问题：

“部署到集群中的容器镜像真的都安全可靠吗？” 🤔

如果开发人员不小心使用了未经验证的外部镜像，或者部署了带有安全漏洞的:latest标签镜像，会发生什么？为了提前阻止这些问题，并安全地保护我们的集群，我们需要一个看门人(Gatekeeper)。今天介绍的功能正是扮演这个角色！

1. 看门人的身份：什么是准入控制器(Admission Controller)？

首先需要理解的基本概念是准入控制器。顾名思义，它就是“控制准入”的家伙。

准入控制器是一个插件，它拦截所有进入Kubernetes API服务器的请求，并执行额外的验证或修改操作。由于用户创建Pod或更新服务等所有操作都必须经过API服务器，因此在这里设置一个看门人，就可以控制所有进入集群内部的事物。

准入控制器主要分为两种：

✍️ Mutating Admission Webhook (修改型Webhook)：修改或更改传入的请求。例如，可以强制在创建特定Pod时添加一个Sidecar容器。
✅ Validating Admission Webhook (验证型Webhook)：验证传入的请求，如果不符合策略则拒绝。例如，可以创建一条规则，要求所有Pod都必须包含owner标签。

今天的主角ImagePolicyWebhook正是这种Validating Admission Webhook的一种。

2. 看门人配置文件：AdmissionConfiguration 📜

那么，如何配置和管理这些聪明的看门人（准入控制器）呢？这就是AdmissionConfiguration文件的作用。

AdmissionConfiguration是一个配置文件，它定义了kube-apiserver应该使用哪些准入控制插件，以何种顺序，以及如何使用。它就像给俱乐部看门人写的一份指示，告诉他们“今天只允许名单上的人进入！”

通过这个文件，除了内置的准入控制器之外，我们还可以连接我们自己创建的外部Webhook。

主要组成部分

以下是AdmissionConfiguration文件的一个简单示例：

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook  # 要使用的准入控制器的名称
    configuration:
      imagePolicy:
        kubeConfigFile: /path/to/webhook/kubeconfig.yaml # Webhook服务器的认证信息
        allowTTL: 50 # 缓存TTL (秒)
        denyTTL: 50
        retryBackoff: 500 # 重试间隔 (毫秒)
        defaultAllow: true # Webhook调用失败时是否默认允许

plugins：在这里定义我们要启用的准入控制器列表。
name：指定要启用的插件名称。今天的主角ImagePolicyWebhook就在这里。
configuration：这部分定义了该插件的详细设置。它包括如何连接到Webhook服务器的信息（kubeConfigFile）等。

将此配置文件作为kube-apiserver的启动参数(–admission-control-config-file)传递后，API服务器将读取此文件，并正式任命指定的Webhook为集群的“看门人”。

3. 镜像专家：ImagePolicyWebhook 👮‍♀️

现在，终于到了了解核心内容ImagePolicyWebhook的时候了！

顾名思义，这个Webhook是一个专门用于检查容器镜像(Image)相关策略的Validating Admission Webhook。当集群中创建或更新Pod时，它就像一位专业的警察，仔细审查该Pod打算使用的所有容器镜像。

ImagePolicyWebhook为何强大？

强制特定注册表：可以强制使用经过授权的注册表，例如“我们公司只能使用来自private-registry.mycorp.com的镜像！”，从而增强安全性。
禁止:latest标签：为了稳定性，可以强制使用明确的版本标签（例如：nginx:1.21.6），并阻止使用不可预测的:latest标签。
镜像签名验证：可以强制只部署使用Notary等工具签名的可信镜像。

工作方式 ⚙️

ImagePolicyWebhook的工作流程如下：

🧑‍💻 用户请求：开发人员发送包含镜像的Pod创建请求。(kubectl apply -f my-pod.yaml)
➡️ API服务器接收：kube-apiserver接收此请求。
🤔 策略检查：API服务器查看AdmissionConfiguration并判断：“啊，我需要调用ImagePolicyWebhook！”
📞 调用Webhook：API服务器将需要检查的镜像信息封装到ImageReview对象中，并向外部Webhook服务器（我们自己实现的服务器）发送HTTP POST请求。
🧐 Webhook服务器审查：Webhook服务器接收ImageReview请求，将镜像名称、标签等与内部策略进行比较，然后决定是否允许。
👍/👎 发送结果：Webhook服务器将审查结果发送回API服务器。（{“allowed”: true} 或 {“allowed”: false, “reason”: “只允许使用内部注册表镜像。”}）
✅/❌ 最终决定：API服务器根据Webhook的响应，最终批准请求，或向用户发送错误消息并拒绝请求。

🎬 结论：安全集群的必经之门

总而言之，AdmissionConfiguration是告诉我们如何部署和操作集群看门人（准入控制器）的配置指南，而ImagePolicyWebhook则是其中专门审查容器镜像、负责集群安全的严格镜像专家。

将这两者结合使用，您不仅可以部署应用程序，还可以建立一个强大的安全体系，确保“只根据既定规则和策略部署安全可靠的应用程序”。这是稳定集群运营和DevSecOps文化的核心部分。

现在，何不在您的集群中也设置一个可靠的看门人呢？

Kubernetes, AdmissionControl, ImagePolicyWebhook, Security, K8s, DevSecOps, Policy, Kubernetes, 安全