Currently, the operator checks if RBAC resources exist, and if not they are created. If they do exist, nothing happens.
That means if a new version of the operator was released with changes to the RBAC resources, for example removing an unnecessary rule from the Role, then this change would not propagate to existing Roles.
To support this future scenario, this PR changes the behaviour to create or update the Role and RoleBinding.
It doesn't change the behaviour for the ServiceAccount resource, because unlike the Role or RoleBinding, it's expected a user may update the ServiceAccount to add things like annotations. And updating the ServiceAccount would reverse such changes by the user.
(The operator needs to be refactored to use SSA (server-side apply), to permit changes both by the user and the operator).
Currently, the operator checks if RBAC resources exist, and if not they are created. If they do exist, nothing happens.
That means if a new version of the operator was released with changes to the RBAC resources, for example removing an unnecessary rule from the Role, then this change would not propagate to existing Roles.
To support this future scenario, this PR changes the behaviour to create or update the Role and RoleBinding.
It doesn't change the behaviour for the ServiceAccount resource, because unlike the Role or RoleBinding, it's expected a user may update the ServiceAccount to add things like annotations. And updating the ServiceAccount would reverse such changes by the user.
(The operator needs to be refactored to use SSA (server-side apply), to permit changes both by the user and the operator).