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
I ran into a slight issue that happened since the helm chart split the worker and server deployment.
The worker will now happily generate a service account (via a non-configurable name), but the server deployment will use default. When combined with the volume configuration applying on both deployments, if you are using csi secret store to load in secrets from HashiCorp Vault there are SA's that need access where there used to be just one.
The most straight-forward way to fix this would probably be to just have the worker and server use the same service account once it is created, but for max-security deployments it might make more sense to make both the SAs and the volumes + volumeMounts individually configurable.
The text was updated successfully, but these errors were encountered:
If I find time (which might be a while) I can try to add this, but since I see at least a couple of ways to approach it I didn't want to just drop in a PR.
This is indeed currently the case for security, since the worker is the only deployment actually accessing the K8s api and the server container doesn't need it.
We could add a separate SA for the server deployment and not bind and roles to it, which would allow people to bind custom roles to it
I ran into a slight issue that happened since the helm chart split the worker and server deployment.
The worker will now happily generate a service account (via a non-configurable name), but the server deployment will use default. When combined with the volume configuration applying on both deployments, if you are using csi secret store to load in secrets from HashiCorp Vault there are SA's that need access where there used to be just one.
The most straight-forward way to fix this would probably be to just have the worker and server use the same service account once it is created, but for max-security deployments it might make more sense to make both the SAs and the volumes + volumeMounts individually configurable.
The text was updated successfully, but these errors were encountered: