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
Currently, enabling SSO requires the Argo-Server Service Account to have Cluster Permission on Secrets and ServiceAccounts.
This is a potential security risk if the cluster includes additional, higher level configurations.
I did some research on code-basis and since the argo-server is already making use of 'ssoNamespace'. I think the changes required would only need a few adjustments on how the serviceaccounts are fetched, if an optional flag like "ssoNamespaces" would be implemented.
If you agree on this feature, I am more than happy to contribute.
Use Cases
We are currently evaluating between a cluster-wide or multiple, namespaced instances for Argo-Workflows.
Due to our team structure, we do not hold Cluster-Admin permissions. However, we do have support and a process of installing CRDs, Operators and carefuly picked out ClusterRoleBindings.
The ClusterRoleBindings may only include permissions related to the CRDs we create and other resources that do not compromise secrets.
Because of how the SSO works, the argo-server will scan all serviceaccounts and all secrets on cluster-scope.
Limiting the namespaces for the SSO would allow to set namespaced roleBindings and still allow a cluster-wide instance.
Message from the maintainers:
Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.
The text was updated successfully, but these errors were encountered:
Summary
Currently, enabling SSO requires the Argo-Server Service Account to have Cluster Permission on Secrets and ServiceAccounts.
This is a potential security risk if the cluster includes additional, higher level configurations.
I did some research on code-basis and since the argo-server is already making use of 'ssoNamespace'. I think the changes required would only need a few adjustments on how the serviceaccounts are fetched, if an optional flag like "ssoNamespaces" would be implemented.
If you agree on this feature, I am more than happy to contribute.
Use Cases
We are currently evaluating between a cluster-wide or multiple, namespaced instances for Argo-Workflows.
Due to our team structure, we do not hold Cluster-Admin permissions. However, we do have support and a process of installing CRDs, Operators and carefuly picked out ClusterRoleBindings.
The ClusterRoleBindings may only include permissions related to the CRDs we create and other resources that do not compromise secrets.
Because of how the SSO works, the argo-server will scan all serviceaccounts and all secrets on cluster-scope.
Limiting the namespaces for the SSO would allow to set namespaced roleBindings and still allow a cluster-wide instance.
Message from the maintainers:
Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.
The text was updated successfully, but these errors were encountered: