Go to live blocker from audit perspective due to too wide RBAC exec pod rights in trident operator

[Krishna-Netapp-cgi]

Go to live blocker from audit perspective due to too wide RBAC exec pod rights in trident operator

[wonderland]

I guess this needs a little more context?

[damalapatinithinnaidu-afk]

Query:

We have a go to live blocker from audit perspective due to too wide RBAC exec pod rights in trident operator.

pods/exec [] [trident-csi] [delete update patch]

pods/exec [] [trident] [delete update patch]

pods/exec [] [] [get list create]

"This permission appears related to Trident operator lifecycle/version-management behavior, not to ordinary Trident runtime data-plane operations."
Could you provide a documented justification for pods/exec,
a supported way to disable that behavior,
or a reduced-RBAC profile for production clusters.

[clintonk]

Hello, @damalapatinithinnaidu-afk. The Trident operator uses exec to detect the Trident version inside a transient pod as well as to detect a completed Trident installation by invoking tridentctl inside the controller pod. Trident itself does not require exec, nor does it request that privilege in its RBAC. If having exec in the operator is a problem for you, you could reduce its replicas to 0 after Trident is installed, or you could simply install Trident using tridentctl.