Open
Description
After we implemented #737, users now provide their own service accounts that must have the permissions necessary to manage the lifecycle of a bundle.
This epics depends on #988 and #1424.
The service account needs CRUD on each group resource of each unique object in the bundle
- If there are any ClusterRoles, Roles, ClusterRoleBindings, and/or RoleBindings, the service account additionally needs:
- Either
escalate
/bind
to allow the service account to create permissions it itself does not have - OR permissions that match the permissions that are granted by the RBAC in the bundle.
- Either
- If the cluster uses the
OwnerReferencesPermissionEnforcement
admission plugin, thenclusterextensions/finalizers
update
permission is also required. See https://github.com/operator-framework/operator-controller/blob/76bb90f4568e00d1e1f261cc53ac7b37501eb03c/docs/drafts/permissions-for-owner-references-permission-enforcement-plugin.md
There are some technical challenges here:
- The bundle must be pulled, extracted, and rendered in order to see what would be deployed.
- User input from [epic] ClusterExtension parameters passed through to templating engine #381 will cause the contents of the rendered manifest to be configurable, potentially resulting in a different set of RBAC required.
Metadata
Metadata
Assignees
Type
Projects
Status
No status