jwitko commented on PR #13747: URL: https://github.com/apache/druid/pull/13747#issuecomment-1422665417
> can you elaborate a bit more on "Enabling per-service serviceAccounts allows for finer grained RBAC"? Maybe take us through an example use-case that you want to implement on your own cluster. Absolutely. In its current state the helm chart does not allow for configuration of service accounts on the deployments/statefulsets. This means your only choice is to use the `default` service account in whatever namespace you deploy into. Because of this, if you share the namespace with any other applications and they also use the default namespace you are now forced to share any roles/rolebindings that affect the `default` service account. So if you want to isolate permissions this leaves your only option as putting druid in its own namespace so that nothing else shares the default service account. Assuming you take the above approach and druid is now in its own namespace you have another issue. Different druid services require different levels of permissions. For example the `broker` does not require the ability to start kubernetes jobs but the `overlord` service does if you're using the `druid-kubernetes-overlord-extensions` extension. With a single service account shared for all services you have no choice but to give all the services the ability to start jobs if you want to use the `druid-kubernetes-overlord-extensions` which goes against the principal of least privilege. You can extrapolate this even further by bringing the `druid-s3-extensions` into the conversation. If you want to leverage [AWS iRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) for a better security posture and so that you don't have to store AWS credentials in your cluster and find a way to securely get them there you now have to give every single druid pr ocess the same IAM privileges in AWS if they are all using the same service account. By merging this PR we get per-service service accounts which allow us to apply Kubernetes native RBAC and additional external privileges (like iRSA) on a per-service level so that we don't have to give unnecessary privileges to services that don't require them. @abhishekagarwal87 does that make sense? Let me know if you have any questions or disagree with any of the above. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@druid.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@druid.apache.org For additional commands, e-mail: commits-h...@druid.apache.org
