You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Argo Events, when installed in a cluster-scoped mode, currently require cluster-wide list/watch/get on Secrets. The controller will simply not start if the RBAC is removed and the controller can't start the watch. This issue is to remove this hard requirement for cluster-wide secret list/watch/get.
Describe the solution you'd like
The reason argo-events watches secrets, is because it re-queues the parent EventBus object for whenever its child Secret changes. But since the child secret is controlled by the controller (not by admins), this is largely unnecessary. Also, it will eventually be recreated/updated during normal resync periods of EventBus objects.
I think Argo Events can improve its security by removing this watch requirement, and allowing administrators to allow list/get Secret calls at a namespace granularity.
This is how both Argo Workflows and Argo Rollouts are implemented. See:
Tried patching the RBAC manually but the way the code is implemented is impossible. Currently, the only way to run argo-events in a locked-down cluster is to run multiple instances of it. But this is an expensive and heavy-handed workaround which also does not allow config reuse.
Additional context
Chatted with @whynowy about this and he agrees this is something that can be accomplished.
Message from the maintainers:
If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.
The text was updated successfully, but these errors were encountered:
Argo Events, when installed in a cluster-scoped mode, currently require cluster-wide
list
/watch
/get
on Secrets. The controller will simply not start if the RBAC is removed and the controller can't start the watch. This issue is to remove this hard requirement for cluster-wide secretlist
/watch
/get
.Describe the solution you'd like
The reason argo-events watches secrets, is because it re-queues the parent EventBus object for whenever its child Secret changes. But since the child secret is controlled by the controller (not by admins), this is largely unnecessary. Also, it will eventually be recreated/updated during normal resync periods of EventBus objects.
I think Argo Events can improve its security by removing this watch requirement, and allowing administrators to allow
list/get
Secret calls at a namespace granularity.This is how both Argo Workflows and Argo Rollouts are implemented. See:
List
on all Secrets argo-workflows#8534Describe alternatives you've considered
Tried patching the RBAC manually but the way the code is implemented is impossible. Currently, the only way to run argo-events in a locked-down cluster is to run multiple instances of it. But this is an expensive and heavy-handed workaround which also does not allow config reuse.
Additional context
Chatted with @whynowy about this and he agrees this is something that can be accomplished.
Message from the maintainers:
If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.
The text was updated successfully, but these errors were encountered: