Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Allow helm chart to toggle ClusterRoleBinding creation (follow up from #5228) #7577

Open
zaccari opened this issue Mar 28, 2025 · 4 comments
Labels
proposal An issue that proposes a feature request ready for refinement An issue that was triaged and it is ready to be refined

Comments

@zaccari
Copy link

zaccari commented Mar 28, 2025

Is your feature request related to a problem? Please describe.
I'm working with a solution that has the nginx-ingress-controller (with nginx plus) deployed to multiple namespaces within the same k8s cluster. The rbac within each namespace works correctly, but the ClusterRoleBinding only knows about the last chart that was deployed, even with rbac.clusterrole.create: false. This has lead to some interesting work arounds about owning the ClusterRoleBinding for dynamically deployed controllers.

Describe the solution you'd like
A setting that allows a user to toggle creation of the ClusterRoleBinding, in order to provide a better suited cluster level RBAC.

Describe alternatives you've considered
I had hoped that using rbac.clusterrole.create: false would not install the ClusterRoleBinding, but that seems to have been left out (intentionally?) of the issue that initially implemented the logic in #5228.

Additional context
Being able to test within namespaces seems to be limited by the chart owning the ClusterRoleBinding, even if the ultimate solution will use a cluster-wide chart and controller.

@zaccari zaccari added the proposal An issue that proposes a feature request label Mar 28, 2025
Copy link

Hi @zaccari thanks for reporting!

Be sure to check out the docs and the Contributing Guidelines while you wait for a human to take a look at this 🙂

Cheers!

@vepatel vepatel added the ready for refinement An issue that was triaged and it is ready to be refined label Mar 28, 2025
@hafe
Copy link
Contributor

hafe commented Mar 28, 2025

Guess I thought that you always need a CRB, it is the content of the CR that is important. Guess you would need to use a different helm release name to get unique names for the CRB

@zaccari
Copy link
Author

zaccari commented Mar 28, 2025

To clarify: A CRB is needed, but it needs to "know" about the service accounts in any namespaces the controller is deployed to. For example:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: nginx-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress
subjects:
  - kind: ServiceAccount
    name: nginx-ingress
    namespace: app1
  - kind: ServiceAccount
    name: nginx-ingress
    namespace: app2
  - kind: ServiceAccount
    name: nginx-ingress
    namespace: app3

If I deploy the helm chart to the app3 namespace today, it will create a CRB with only app3 in it. In this case I would like to own the CRB for the cluster, and disable the ability for the helm chart to create a CRB when deploying to app3, so that I can ensure all namespaces have an entry.

@zaccari
Copy link
Author

zaccari commented Mar 28, 2025

Ah, I haven't tried using a different helm release name for the CR/CRBs across namespaces. That is indeed a possible work around for this use case.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
proposal An issue that proposes a feature request ready for refinement An issue that was triaged and it is ready to be refined
Projects
None yet
Development

No branches or pull requests

3 participants