Based on the NetApp Knowledge Base article Trident DaemonSet Deployment Fails on AKS: “Privilege escalation container is not allowed” Due to Azure Policy (KCS 2010800282). Only claims published in that article are asserted here.
TRIDENT AKS AZURE KUBERNETES NETAPP Oct 11, 2026The failure: node pods never start
Deploy NetApp Trident on Azure Kubernetes Service and, on a
cluster that enforces the Azure Policy set for privilege escalation, the node pods never come up.
The DaemonSet trident-node-linux is accepted, but its pods are rejected before they
run, and the cluster records a very specific reason:
Policy constraint: azurepolicy-k8sazurev4noprivilegeescalatio-<ID>
Denied container: trident-main (DaemonSet trident-node-linux)
Reason: "Privilege escalation container is not allowed"
Reference: aka.ms/aks/deployment-safeguardsThe Knowledge Base entry (KCS 2010800282, last updated 10 October 2026) states it
plainly: the Trident deployment fails because the AKS admission webhook
validation.gatekeeper.sh denies the DaemonSet pod creation on privilege-escalation
grounds. Nothing is wrong with the storage backend — admission says no.
Why an Azure Policy stops a storage driver
Pod admission on AKS is not Trident’s code path. Gatekeeper evaluates every incoming pod
against the policy assignments on the cluster. The constraint name
azurepolicy-k8sazurev4noprivilegeescalatio-<ID> corresponds to the built-in policy
“Kubernetes clusters should not allow container privilege escalation” (cited in CIS
benchmark 5.2.5). The Trident node DaemonSet ships a pod spec the policy classifies as
privilege escalation, so trident-main is denied at the admission step and the node
DaemonSet sits with zero ready pods.
The practical consequence: this is an environment problem, not a version problem. If a cluster hardens privilege escalation, a storage plugin that needs node-level access will be the first thing to trip the policy — even though it is exactly the kind of workload the cluster owner intended to run.
What it applies to
- NetApp Trident — all versions
- Azure Kubernetes Service (AKS)
- ONTAP, including 9.17.1P10 and later
- AFF-C60 and other ONTAP-based storage systems
In other words, the version of ONTAP is irrelevant; the trigger is the AKS policy configuration in front of it.
Confirming it on your own cluster
Before you change anything, prove which layer is rejecting the pod. The Denied container name and the constraint string are the fingerprints:
kubectl -n trident get pods
kubectl -n trident describe daemonset trident-node-linux
kubectl -n trident get events --sort-by=.lastTimestamp | tail -n 20If you see validation.gatekeeper.sh and the
azurepolicy-k8sazurev4noprivilegeescalatio-<ID> constraint, you are looking at the
policy, not at Trident, the CSI layer, or ONTAP. Our
troubleshooting hub covers the storage-side failure modes if the
event log shows something else.
Getting past it
Because the blocker is an Azure Policy assignment, the fix lives in policy, not in Trident. The NetApp KB documents the resolution behind a support sign-in. Microsoft has its own relevant caveat: its AKS troubleshooting guidance documents a case where a privileged-container exclusion does not take effect, so if you exempt the Trident namespace, verify the exemption actually applied rather than assuming it did. A denied pod re-appears within seconds if the policy is still evaluating it.
Why it matters
Trident is how ONTAP-backed volumes reach Kubernetes, so a single admission policy can take an
entire AKS cluster’s persistent storage offline at deploy time — with a message that names the
container and the constraint but never mentions NetApp. Recognising the
validation.gatekeeper.sh signature turns a confusing “Trident is broken” report
into a three-minute policy check. The takeaway for storage admins: keep the KB article bookmarked,
and read the admission event before you redeploy.
Sources: NetApp Knowledge Base — KCS 2010800282 · Microsoft Learn — Azure Policy privileged-container exclusion