Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

📖 Document OLMv1 permission model #1380

Open
wants to merge 13 commits into
base: main
Choose a base branch
from
13 changes: 13 additions & 0 deletions docs/concepts/permission-model.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
#### OLMv1 Permission Model

Here we aim to describe the OLMv1 permission model. OLMv1 itself does not have permission to manage the installation and lifecycle of cluster extensions. Rather, it requires that each cluster extension specifies a service account that will be used to manage its bundle contents.
rashmi43 marked this conversation as resolved.
Show resolved Hide resolved


1) The purpose of the service account specified in the ClusterExtension spec, which is to manage everything in (2) below.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the structure of this section is a little bit unclear. Maybe we could call attention to the fact that the installer service account and the service account for the cluster extension's Deployment have different purposes: the first manages the lifecycle of the cluster extensions - so it needs to be able to create/modify the resources packed in the bundle, and assign RBAC to the extension's Deployment SA. And, the second, gives the extension controller the RBAC it needs to do its business.

I think most of that information is already here, we should just restructure it a bit to make clear this distinction and the roles of each of the SAs

2) The contents of the bundle, which may contain more service accounts and RBAC. Since the operator bundle contains its own RBAC, it means the ClusterExtension service account requires either:
- the same set of permissions that are defined in the RBAC that it is trying to create.
- bind/escalate verbs for RBAC, OR
rashmi43 marked this conversation as resolved.
Show resolved Hide resolved
See https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping
4) The OLMv1 operator-controller generates a service account for the deployment and RBAC for the service account based on the contents of the ClusterServiceVersion in much the same way that OLMv0 does. The ClusterExtension CR also defines a service account to deploy and manage the ClusterExtension lifecycle
rashmi43 marked this conversation as resolved.
Show resolved Hide resolved

The ClusterExtension permissions are not added to the deployment. The ClusterExtension service account and the bundle's service accounts are for different purposes. Naming conflicts between the two service accounts can lead to failure of ClusterExtension deployment.