在Box，我们使用Kubernetes（K8）来管理数百种微服务，这些服务使Box能够以PB级数据流转。在部署过程中，我们以声明式配置和自动部署的方式运行kube-applier作为GitOps工作流程的一部分。开发人员将其服务配置（包括K8s清单，docker镜像等）声明到Git存储库中，该存储库需要代码审查和自动检查通过，然后才能将所有更改合并并应用到我们的K8s集群中。和kubectlexec和其他的命令类似，开发人员可以直接与正在运行的容器进行交互，并有可能将其从部署状态中进行更改。这种交互作用可能会破坏在我们的CI/CD管道中执行的变更控制和代码审查过程。此外，它允许这种容器长期继续在生产中接受运输。为了解决此问题，我们利用了K8s准入控制器和kubectl插件，它们可以共同检测并终止任何可能发生突变的容器，并向服务所有者显示事件以提高可见性。
准入控制器，用于处理交互式kubectl命令
我们知道，一旦请求发送到K8s，它就需要由APIServer进行身份验证和授权才能继续。另外，K8s有一个单独的保护层，称为准入控制器，可以在对象保留在etcd中之前拦截请求。APIServer二进制文件中已编译了各种预定义的准入控件（例如，ResourceQuota可以对每个名称空间实施硬资源使用限制）。此外，还有两个名为MutatingAdmissionWebhook和ValidatingAdmissionWebhook的动态准入控件，分别用于更改或验证K8s请求。后者是我们用来检测潜在突变容器的方法。整个过程可以分为三个步骤，详细说明如下。
1.接收交互式kubectl命令的准入请求我们需要首先定义合格的准入网络钩子，以在我们的准入控制器服务中接收特定的请求。例如kubectlexec，出于利益的考虑，我们将Webhook的规则配置为资源为“pods/exec”，操作为“CONNECT”。他们告诉K8sAPIServer，所有“执行”请求都应服从我们的准入控制器服务。我们还指定了一个“url”，该URL给出了我们的服务的位置，并指定了“caBundle”以提供其证书，二者均在“clientConfig”节中。这是我们的ValidatingWebhookConfiguration对象的简短示例：
apiVersion:admissionregistration.k8s.io/v1kind:ValidatingWebhookConfigurationmetadata:name:"example-webhook"webhooks:-name:"admit-pod-exec-webhook"rules:-apiGroups:["*"]apiVersions:["*"]operations:["CONNECT"]resources:["pods/exec"]clientConfig:url:"