Description
When the Datadog operator reconciles a DatadogAgent CR, it generates a ClusterRole for the cluster-agent that includes mutatingwebhookconfigurations permissions scoped to resourceNames: [datadog-webhook]:
- apiGroups: [admissionregistration.k8s.io]
resourceNames: [datadog-webhook]
resources: [validatingwebhookconfigurations, mutatingwebhookconfigurations]
verbs: [get, list, watch, update, delete]
When spec.features.admissionController.webhookName is set to a custom value (e.g. my-custom-webhook), the operator creates a MutatingWebhookConfiguration with that custom name — but the ClusterRole still restricts access to datadog-webhook. This means the cluster-agent cannot manage its own webhook.
Impact
-
Self-healing is broken with custom webhook names — if the MWC is modified or deleted externally, the cluster-agent cannot recreate or update it because the RBAC doesn't permit access to the custom-named resource.
-
Multi-instance clusters — when multiple DatadogAgent CRs exist in different namespaces (e.g. separate teams or tenants sharing a cluster), each instance should manage its own uniquely-named webhook. The current RBAC prevents this since all instances can only access datadog-webhook.
Expected Behavior
The operator-generated ClusterRole should scope mutatingwebhookconfigurations permissions to the actual webhookName configured in the DatadogAgent CR, not the hardcoded default. If spec.features.admissionController.webhookName is set to my-custom-webhook, the ClusterRole should use resourceNames: [my-custom-webhook].
Steps to Reproduce
- Deploy a
DatadogAgent CR with spec.features.admissionController.webhookName: my-custom-webhook
- Inspect the operator-generated ClusterRole for the cluster-agent
- Observe that
resourceNames is still [datadog-webhook] instead of [my-custom-webhook]
- The cluster-agent logs will show RBAC errors when trying to update the custom-named MWC
Environment
- Operator version: 1.14.0
- Kubernetes: 1.29+
Description
When the Datadog operator reconciles a
DatadogAgentCR, it generates a ClusterRole for the cluster-agent that includesmutatingwebhookconfigurationspermissions scoped toresourceNames: [datadog-webhook]:When
spec.features.admissionController.webhookNameis set to a custom value (e.g.my-custom-webhook), the operator creates a MutatingWebhookConfiguration with that custom name — but the ClusterRole still restricts access todatadog-webhook. This means the cluster-agent cannot manage its own webhook.Impact
Self-healing is broken with custom webhook names — if the MWC is modified or deleted externally, the cluster-agent cannot recreate or update it because the RBAC doesn't permit access to the custom-named resource.
Multi-instance clusters — when multiple
DatadogAgentCRs exist in different namespaces (e.g. separate teams or tenants sharing a cluster), each instance should manage its own uniquely-named webhook. The current RBAC prevents this since all instances can only accessdatadog-webhook.Expected Behavior
The operator-generated ClusterRole should scope
mutatingwebhookconfigurationspermissions to the actualwebhookNameconfigured in the DatadogAgent CR, not the hardcoded default. Ifspec.features.admissionController.webhookNameis set tomy-custom-webhook, the ClusterRole should useresourceNames: [my-custom-webhook].Steps to Reproduce
DatadogAgentCR withspec.features.admissionController.webhookName: my-custom-webhookresourceNamesis still[datadog-webhook]instead of[my-custom-webhook]Environment