Describe the bug
The microsoft.dapr extension cannot be installed on an AKS Automatic cluster. The Dapr pods enter CrashLoopBackOff because the aks-managed-protect-system-namespaces ValidatingAdmissionPolicy blocks them from creating the dapr-trust-bundle Secret and similar ConfigMaps in the dapr-system namespace, causing the extension installation to fail.
This is the same root cause as #5645 (which affected microsoft.flux), but for the Dapr extension. The fix released for Flux did not extend to Dapr — the dapr-system service accounts are still not exempted from the policy.
To Reproduce
- Create an AKS Automatic cluster
- Install the Dapr extension:
az k8s-extension create \
--resource-group <resource-group> \
--cluster-name <cluster-name> \
--cluster-type managedClusters \
--name dapr \
--extension-type microsoft.dapr \
--auto-upgrade-minor-version true
- Observe that Dapr pods in
dapr-system enter CrashLoopBackOff
- The extension installation fails with a timeout/rollback error similar to:
ExtensionOperationFailed: Helm installation failed : Timed out waiting for
the resource to come to a ready/completed state
Expected behavior
The microsoft.dapr extension should install and run on AKS Automatic without errors. As a Microsoft-managed extension, its service accounts should be exempt from the aks-managed-protect-system-namespaces policy, consistent with how other managed namespaces are treated.
Root cause
The dapr-system service accounts (e.g. dapr-operator, dapr-sentry, dapr-injector) are blocked from creating Secrets and ConfigMaps in the dapr-system namespace by the aks-managed-protect-system-namespaces ValidatingAdmissionPolicy:
secrets "dapr-trust-bundle" is forbidden: ValidatingAdmissionPolicy
'aks-managed-protect-system-namespaces' with binding
'aks-managed-protect-system-namespaces-binding' denied request:
Modification of resources in managed system namespaces is not allowed
The policy currently exempts service accounts from kube-system, gatekeeper-system, app-routing-system, and aks-istio-system — but not dapr-system, despite the Dapr extension being a Microsoft-managed AKS component deployed into that namespace.
Adding system:serviceaccounts:dapr-system to the exempt groups in the aks-managed-protect-system-namespaces ValidatingAdmissionPolicy should resolve this issue, consistent with the fix applied for microsoft.flux in #5645.
Environment (please complete the following information):
- CLI Version: latest
- Kubernetes version: 1.34.4
- AKS tier: Automatic
- Dapr extension version: latest
Additional context
This is a direct follow-up to #5645 at the request of @sjwaight (see #5645 (comment)).
Describe the bug
The
microsoft.daprextension cannot be installed on an AKS Automatic cluster. The Dapr pods enterCrashLoopBackOffbecause theaks-managed-protect-system-namespacesValidatingAdmissionPolicy blocks them from creating thedapr-trust-bundleSecret and similar ConfigMaps in thedapr-systemnamespace, causing the extension installation to fail.This is the same root cause as #5645 (which affected
microsoft.flux), but for the Dapr extension. The fix released for Flux did not extend to Dapr — thedapr-systemservice accounts are still not exempted from the policy.To Reproduce
dapr-systementerCrashLoopBackOffExpected behavior
The
microsoft.daprextension should install and run on AKS Automatic without errors. As a Microsoft-managed extension, its service accounts should be exempt from theaks-managed-protect-system-namespacespolicy, consistent with how other managed namespaces are treated.Root cause
The
dapr-systemservice accounts (e.g.dapr-operator,dapr-sentry,dapr-injector) are blocked from creating Secrets and ConfigMaps in thedapr-systemnamespace by theaks-managed-protect-system-namespacesValidatingAdmissionPolicy:The policy currently exempts service accounts from
kube-system,gatekeeper-system,app-routing-system, andaks-istio-system— but notdapr-system, despite the Dapr extension being a Microsoft-managed AKS component deployed into that namespace.Adding
system:serviceaccounts:dapr-systemto the exempt groups in theaks-managed-protect-system-namespacesValidatingAdmissionPolicy should resolve this issue, consistent with the fix applied formicrosoft.fluxin #5645.Environment (please complete the following information):
Additional context
This is a direct follow-up to #5645 at the request of @sjwaight (see #5645 (comment)).