应用AKS内置container-no-privilege-escalation策略导致az aks command invoke失效是否为预期？

这是应用该Azure内置策略后的预期影响，原因如下：

az aks command invoke工具执行命令时，会在AKS集群中自动创建临时Pod，该Pod包含init-command和user-command两个容器。这两个容器默认配置了allowPrivilegeEscalation: true——这是执行集群命令所需的权限设置。

而你应用的container-no-privilege-escalation内置策略，核心规则就是强制所有容器的allowPrivilegeEscalation字段设为false，禁止任何形式的权限提升操作。当Gatekeeper准入webhook检测到临时Pod的容器违反该规则时，就会拒绝Pod的创建请求，触发你遇到的错误：

(KubernetesOperationError) Failed to run command in managed cluster due to kubernetes failure. details: admission webhook "validation.gatekeeper.sh" denied the request: [azurepolicy-k8sazurev3noprivilegeescalatio-adff37e713cffbf58639] Privilege escalation container is not allowed: init-command
[azurepolicy-k8sazurev3noprivilegeescalatio-adff37e713cffbf58639] Privilege escalation container is not allowed: user-command
Code: KubernetesOperationError
Message: Failed to run command in managed cluster due to kubernetes failure. details: admission webhook "validation.gatekeeper.sh" denied the request: [azurepolicy-k8sazurev3noprivilegeescalatio-adff37e713cffbf58639] Privilege escalation container is not allowed: init-command
[azurepolicy-k8sazurev3noprivilegeescalatio-adff37e713cffbf58639] Privilege escalation container is not allowed: user-command

如果需要继续使用az aks command invoke，可以考虑以下方案：

• 针对该工具创建的临时Pod添加策略豁免：比如根据Pod的特定标签或所在命名空间，在策略中配置例外规则
• 临时调整策略规则，允许特定场景下的权限提升（需评估安全风险）
• 改用直接通过kubectl连接集群执行命令的方式（前提是你有权限获取集群kubeconfig）

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