GKE集群中如何配置或查看DenyEscalatingExec准入控制器？

Let’s break down your questions and solutions clearly, since securing Jenkins with Docker in GKE is a common (and important) challenge:

1. Is DenyEscalatingExec enabled by default in GKE? #

Yes, Google Kubernetes Engine ships with a standard set of admission controllers enabled out of the box, and DenyEscalatingExec is part of this default list. This controller blocks exec/attach requests to pods running with escalated privileges (like root user or privileged mode), which directly mitigates the privilege escalation risk from mounting docker.sock.

2. How to verify active admission controllers in your GKE cluster? #

Since GKE manages the control plane, you can’t edit the API Server config directly, but you can inspect the running API Server pods to confirm enabled plugins:

• First, list the kube-apiserver pods in the kube-system namespace:

  kubectl get pods -n kube-system | grep kube-apiserver
  

• Then, exec into one of these pods to check the API Server’s startup arguments:

  kubectl exec -n kube-system <kube-apiserver-pod-name> -- cat /proc/1/cmdline | tr '\0' '\n' | grep enable-admission-plugins
  

  Look for DenyEscalatingExec in the comma-separated list of enabled plugins.

3. Can you customize admission controllers in GKE? #

Short answer: No, you can’t directly modify the API Server’s admission controller list in GKE. Google maintains control plane components (including the API Server) to ensure cluster stability and security, so direct edits are restricted.

But there are better, GKE-native ways to address your core security concern (privilege escalation from docker.sock mounts):

Alternative Solutions to Secure Jenkins Slaves #

• Use Jenkins Kubernetes Plugin with DinD/Kaniko: Skip mounting docker.sock entirely. Run Jenkins slave pods with Docker-in-Docker (DinD) containers, or use Kaniko to build images without needing a host Docker daemon. This keeps builds isolated from the node’s filesystem.
• Enforce Pod Security Standards (PSS): GKE supports PSS, which lets you define policies to block privileged pods, restrict host filesystem mounts (like docker.sock), and enforce non-root user runs. Apply these at the namespace or cluster level.
• Implement OPA Gatekeeper: For granular, custom rules, use Gatekeeper (an admission webhook) to create policies that only allow docker.sock mounts for trusted pods (e.g., restricted to specific namespaces or service accounts).

内容的提问来源于stack exchange，提问作者criswell