remove rbac Secrets from app rules

[dan0sh]

Hi @casibbald i, I would like to start discussion about this PR

[erikgb]

@DanielAntos90, I think your link is broken. But I am guessing you are referring to #4203. I have created PR which will fix your issue + many others: #4666. Are you able to drop your thoughts on this PR?

[dan0sh]

Thanks for reply, I have fixed the link.

[dan0sh]

As I described in PR, in our setup, developers do not have permission to access Kubernetes Secrets due to security policies. The restriction on Weave GitOps side prevents developers from observing or managing (e.g., pausing reconciliation) Kustomization and HelmRelease objects.

Removing the restriction on accessing Secrets will allow Weave GitOps to display the required objects while still enforcing security policies.

Currently, this is a blocker for us—we are unable to test your latest release. We need to build it with these adjustments on our side to proceed. We have been using this change for almost a year without any issues, and it has worked seamlessly in our setup.

[erikgb]

I think the access to secrets is required for multi-cluster setup. Can you confirm that you are NOT using this feature @DanielAntos90?

[dan0sh]

We are not using a multi-cluster setup, although we currently have six clusters running this UI. Are there any documents about this? I’m interested in learning more.

Also, I thought the secrets RBAC permission was required to retrieve information from HelmReleases.

[casibbald]

@erikgb
Would optionally flagging & moving resources to a config read at start time be too heavy processing-wise at runtime?

[erikgb]

I am not sure if I understand your suggestion? Could you elaborate, please? To me, the current setup uses a heavy mechanism to check access to namespace. And the API used is not authoritative - as far as I understand.

[dan0sh]

By the way, I just run your latest changes from the main branch on Kubernetes 1.29.x without any issues. 🙂

[casibbald]

The following PR #4697 is very much a concept, but I thought something like this could cater to user's needs.

We just have to determine how best to lock it down.

[dan0sh]

It seems good to me. I'm looking forward to it being released

[dan0sh]

Today, I confirmed that RBAC permissions for secrets (get) are required for Helm releases. Without these permissions, you are unable to observe the objects deployed by Helm."

Would it be possible to modify the behavior so that Helm releases can be observed without requiring RBAC permissions for secrets?