Closed msau42 closed 1 year ago
Hi @msau42,
Thanks for opening this issue. With the Trident 22.07 release we completed an investigation of the permissions needed by Trident. This primarily focused on the minimal set of permissions needed by the Trident daemonset Pods. This set of permissions is largely influenced by Kubernetes, the CSI Spec, and Linux.
We are planning on separating out the controller and daemonset service accounts for the Trident 22.10 release as you have suggested.
The team has also been discussing how to reduce RBAC permissions in both the Operator and when using tridentctl to install Trident. There are more RBAC permissions that can potentially be reduced by removing CRD creation from the Operator's install functionality. Many of the RBAC permissions that are currently needed in the Operator are only required at install/upgrade time. We do have some customers that set the Operator's replicas value to 0 after completing an upgrade as a mitigation strategy.
Thanks for sharing the diff of RBAC changes that you've found work for your Trident deployments. It is a good example of another way to separate RBAC permissions depending on the customer's need to use the Operator or not.
Glad to hear, thanks!
Suggested RBAC improvements were completed with the Trident v23.01 release. Please let us know if these changes don't meet with expectations.
Describe the solution you'd like We have removed many RBAC permissions from Trident for ONTAP deployments. The biggest improvements IMO are:
We have also been able to reduce many permissions because we don't use the operator to deploy and instead manually deploy the Trident controller and daemonset. Consider making these improvements and also separating out the operator to have its own set of permissions.
Here's a diff of the RBAC changes we have made. I added some comments explaining why they were modified/removed.
Separating out controller and daemonset service accounts: