Skip to content

feat(observability): grant Target Allocator CRD watch RBAC - #327

Open
wenegiemepraise wants to merge 2 commits into
aws-observability:mainfrom
wenegiemepraise:ta-crd-resilience-rbac
Open

feat(observability): grant Target Allocator CRD watch RBAC#327
wenegiemepraise wants to merge 2 commits into
aws-observability:mainfrom
wenegiemepraise:ta-crd-resilience-rbac

Conversation

@wenegiemepraise

@wenegiemepraise wenegiemepraise commented Jul 6, 2026

Copy link
Copy Markdown

Summary

Grant the Target Allocator (TA) get;list;watch on customresourcedefinitions
(apiextensions.k8s.io), scoped under the existing prometheus-CR RBAC gate

Companion to operator PR aws/amazon-cloudwatch-agent-operator#394 ("target-allocator: tolerate missing
ServiceMonitor/PodMonitor CRDs"). That change makes the TA watch the SM/PM
CustomResourceDefinitions so it can start/stop each monitor informer as the CRD
appears or disappears. This PR supplies the RBAC that watch requires.

Why

The operator-side change adds an informer over CustomResourceDefinition objects.
Without a grant on customresourcedefinitions, that informer is denied at runtime:

Failed to watch *v1.CustomResourceDefinition: customresourcedefinitions.apiextensions.k8s.io is forbidden:
User "system:serviceaccount:amazon-cloudwatch:cloudwatch-agent-target-allocator" cannot list resource "customresourcedefinitions"

The grant is read-only and cluster-scoped (CRDs are cluster-scoped), the minimum
required for the watch.

Scope / gating

Added inside the existing prometheusCR.enabled gate, right beside the SM/PM
(monitoring.coreos.com) rule — so it renders only when the prometheus-CR scraping
path is enabled, and is inert otherwise. No dependency on the CRD-bundling or flag
work; this slots into the RBAC gate already present on main.

Testing

helm template on the TA ClusterRole:

  • prometheusCR enabled → clusterrole includes both the monitoring.coreos.com
    (podmonitors/servicemonitors) rule and the new apiextensions.k8s.io
    (customresourcedefinitions) rule.
  • prometheusCR disabled (TA still enabled, control) → clusterrole renders with
    neither rule (customresourcedefinitions: 0, podmonitors: 0) — correctly gated.

Grant the Target Allocator get;list;watch on customresourcedefinitions
(apiextensions.k8s.io), scoped under the existing prometheus-CR RBAC gate.

The Target Allocator now watches the ServiceMonitor/PodMonitor
CustomResourceDefinitions so it can start or stop each monitor informer as
the CRD appears or disappears, letting it run healthily regardless of whether
the CRDs are installed yet. That CRD watch requires this read-only,
cluster-scoped grant; without it the informer is denied with Forbidden.

Companion to the operator-side change "target-allocator: tolerate missing
ServiceMonitor/PodMonitor CRDs".
@wenegiemepraise

Copy link
Copy Markdown
Author

Thanks for the feedback, for the merge-time gating: rather than leave it to the merge, I added the customresourcedefinitions rule beside the SM/PM rule under the same $otelCIScrape gate on the scraping foundation branch (#329), so the single-switch path grants it and it can't be dropped. Verified it renders under otelContainerInsights.enabled=true and stays off by default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants