Allow ClusterRole and ClusterRoleBinding in cluster-resources AppProject

[felipesdacosta]

Summary

This PR extends the cluster-resources Argo CD AppProject to allow cluster-scoped RBAC resources.

Closes #21

Changes

• add rbac.authorization.k8s.io/ClusterRole to spec.clusterResourceWhitelist
• add rbac.authorization.k8s.io/ClusterRoleBinding to spec.clusterResourceWhitelist
• update CHANGELOG.md

Why

The current cluster-resources AppProject only allows StorageClass as a cluster-scoped resource.

This prevents clean Argo-managed deployment of cluster-scoped RBAC resources needed for shared platform components such as Alloy log collection.

Without this change, local workarounds lead to:

• SharedResourceWarning on AppProject/cluster-resources
• SyncError for forbidden RBAC resources in the cluster-resources project

Expected outcome

With this change, cluster-resources can manage:

• StorageClass
• ClusterRole
• ClusterRoleBinding

This enables a clean Argo-managed approach for shared cluster-scoped RBAC resources.

[felipesdacosta]

@cableman @ath88

[felipesdacosta]

@hypesystem I'm attaching our overrides/alloy/values.yaml and overrides/prometheus-stack/templates/openwebui-audit-dashboard.yaml.

We call the helm-deployment applications coming from OS2AI as vendor and ours as overrides. So we can override some values for our own setup.

[hypesystem]

@hypesystem I'm attaching our overrides/alloy/values.yaml and overrides/prometheus-stack/templates/openwebui-audit-dashboard.yaml.

We call the helm-deployment applications coming from OS2AI as vendor and ours as overrides. So we can override some values for our own setup.

Maybe I'm missing something obvious, but can you help me understand how these files relate to the PR?

---

Adding the entries in the PR to the clusterResourceWhitelist would allow those resource types to be created in the cluster-resources application: https://github.com/felipesdacosta/helm-deployments/tree/develop/applications/cluster-resources

But you're not adding any resources to that application. So I'm confused about what exactly is driving this need.

Do you need to create some concrete ClusterRole{,Binding}s to make Alloy work as you want? What exactly are those changes that you'd like to make?

Generally it's good practice to have ArgoCD projects be as constrained in resource type as possible to avoid accidental creation, hence the current setting. But of course we can loosen the requirements if there's a concrete driver! I'm just not sure what it is here?

[felipesdacosta]

@hypesystem I'm attaching our overrides/alloy/values.yaml and overrides/prometheus-stack/templates/openwebui-audit-dashboard.yaml.
We call the helm-deployment applications coming from OS2AI as vendor and ours as overrides. So we can override some values for our own setup.

Maybe I'm missing something obvious, but can you help me understand how these files relate to the PR?

Adding the entries in the PR to the clusterResourceWhitelist would allow those resource types to be created in the cluster-resources application: https://github.com/felipesdacosta/helm-deployments/tree/develop/applications/cluster-resources

But you're not adding any resources to that application. So I'm confused about what exactly is driving this need.

Do you need to create some concrete ClusterRole{,Binding}s to make Alloy work as you want? What exactly are those changes that you'd like to make?

Generally it's good practice to have ArgoCD projects be as constrained in resource type as possible to avoid accidental creation, hence the current setting. But of course we can loosen the requirements if there's a concrete driver! I'm just not sure what it is here?

That is a fair question.

There is a concrete driver behind this request.

In our setup, we needed Alloy to collect Open WebUI pod stdout logs. To support that, we created ClusterRole and ClusterRoleBinding resources locally for Alloy so it could discover and read the relevant pod log targets.

The issue we ran into was that Argo CD could not manage those resources cleanly under cluster-resources, because the cluster-resources AppProject only allows StorageClass in clusterResourceWhitelist.

So the purpose of this PR is to enable clean Argo-managed handling of those cluster-scoped RBAC resources, rather than relying on local workarounds.

That said, your point is valid: this PR only changes the AppProject permissions and does not include the actual RBAC manifests that motivated the request.

I am happy to adjust course depending on what you would prefer:

• keep this PR as a small enabling change, or
• come back with a more concrete PR that also shows the actual ClusterRole / ClusterRoleBinding use case and where those resources should live in this repo.

My intention is not to loosen the project unnecessarily, only to support Alloy/Open WebUI log collection use case.

[hypesystem]

@felipesdacosta Is there a particular reason you want ClusterRole{,Binding}s under cluster-resources?

I think they would more naturally belong next to the relevant user agent, in this case in the alloy project which uses them?

We would be open to a PR that enables alloy to collect logs from all pods in the cluster, if that's something you want to look at. Otherwise we'll get around to it at some point, it's on our roadmap.

[felipesdacosta]

@felipesdacosta Is there a particular reason you want ClusterRole{,Binding}s under cluster-resources?

I think they would more naturally belong next to the relevant user agent, in this case in the alloy project which uses them?

We would be open to a PR that enables alloy to collect logs from all pods in the cluster, if that's something you want to look at. Otherwise we'll get around to it at some point, it's on our roadmap.

@hypesystem That makes sense.

The concrete need came from the Alloy override I added for collecting Open WebUI stdout audit logs. In particular, Alloy uses discovery.kubernetes with role = "pod" in the openwebui namespace and then feeds those targets into loki.source.kubernetes. That means Alloy needs Kubernetes API/RBAC permissions for pod discovery/log collection.

However, I agree that the current PR is incomplete as a standalone change. Right now it only allows ClusterRole and ClusterRoleBinding in the cluster-resources AppProject, but it does not include the actual RBAC resources that would need that permission. Also, the current Alloy values have rbac.create: false, so the chart itself will not create those resources from this change alone.

I’ll close this PR for now rather than keep a broad allowlist change open without the concrete RBAC manifests included.

If we still want this upstream, I can come back with a smaller and more complete PR that includes the actual Alloy/Open WebUI RBAC manifests together with the AppProject allowlist change, so the reason for allowing ClusterRole / ClusterRoleBinding is visible in the same PR.

[hypesystem]

@felipesdacosta Let me know if you plan to make a PR that enables log aggregation from all pods. It would be very welcome, and if you have plans to contribute it, I don't want to step on your toes 😄