📖 ServiceAccount conflicts with OLMV1 when deploying existing bundles using OLMV1

[rashmi43]

Existing CSV contains: deployment template RBAC ServiceAccount

When deployed as a ClusterExtension the permissions with the deployment are the ones from its CSV. The CE permissions are not added to the deployment. If the service account name is same, there is an conflict when deploying the CE.

Expectation: The ClusterExtension service account and permissions should be propogated to the deployment. Alternatively, the deployment controller serviceAccount should be overwritten with that listed in the ClusterExtension.

[joelanford]

When deployed as a ClusterExtension the permissions with the deployment are the ones from its CSV

This is expected. Operator-controller generates a service account for the deployment and RBAC for the service account based on the contents of the CSV in much the same way that OLMv0 does.

The CE permissions are not added to the deployment

This is also expected. The CE service account and the bundle's service accounts are for different purposes.

• For registry+v1 bundles, the deployment's service account is separate. Its RBAC is derived purely from the RBAC that is defined in the CSV.
• The CE service account manages the lifecycle of the bundle contents. So it requires RBAC that allows it to manage that lifecycle. This means it needs permission to CRUD the manifests that are defined by the bundle. Also note that since the bundle contains RBAC, that means the CE service account requires either:
  • bind/escalate verbs for RBAC, OR
  • the same set of permissions that are defined in the RBAC that it is trying to create.

See https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping

If the service account name is same, there is an conflict when deploying the CE.

That's correct. The CE service account is used to install/lifecycle bundle content and the deployment service account is used by the controller for the controller to perform its function. They need to be separate.

[joelanford]

I think this is working as intended, but perhaps we should beef up our docs (maybe a new concept doc around OLMv1's permissions model) to clarify this intent.

[rashmi43]

I will work with @perdasilva to get a new document around the OLMv1 permission model