Skip to content

📖 Document OLMv1 permission model #1380

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.

Sign up for GitHub

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

Merged
merged 18 commits into from
Nov 18, 2024
Merged

📖 Document OLMv1 permission model #1380

Changes from 13 commits
Commits
Show all changes
18 commits
Select commit Hold shift + click to select a range
664a51f
changes to derice minimum service account
rashmi43 Sep 9, 2024
75c5f7c
remove headers
rashmi43 Sep 9, 2024
24d93f1
add details about registry+v1 support
rashmi43 Sep 10, 2024
fdf7e9d
render yml correctly
rashmi43 Sep 10, 2024
ba9193d
Merge branch 'operator-framework:main' into main
rashmi43 Oct 8, 2024
4067d8c
Merge branch 'operator-framework:main' into main
rashmi43 Oct 10, 2024
a6b2ebc
Merge branch 'operator-framework:main' into main
rashmi43 Oct 16, 2024
ccfd9a9
create doc for olmv1 permission model
rashmi43 Oct 16, 2024
c40dce6
Delete docs/drafts directory
rashmi43 Oct 16, 2024
2e5fcba
Update permission-model.md
rashmi43 Oct 17, 2024
7bcdd89
update permission models with link
rashmi43 Oct 17, 2024
23223b4
add space
rashmi43 Oct 17, 2024
65aece4
add more structure
rashmi43 Oct 21, 2024
34efe90
incorporate review comments
rashmi43 Oct 24, 2024
3875b46
incorporate review comments
rashmi43 Oct 25, 2024
b27dfa9
pers review comments-s
rashmi43 Nov 6, 2024
a36a0de
example as header-s
rashmi43 Nov 6, 2024
ad0a648
update the example
rashmi43 Nov 15, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions docs/concepts/permission-model.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
#### OLMv1 Permission Model

Here we aim to describe the OLMv1 permission model. OLMv1 does not have permissions to manage the installation and lifecycle of cluster extensions. Rather, it requires that each cluster extension specify a service account that will be used to manage its bundle contents. The cluster extension service account permissions are a superset of the permissions specified for the service account in the operator bundle. It maintains a distinction with the operator bundle service account.

To understand the permission model, lets see the scope of the the service accounts associated with and part of the ClusterExtension deployment:

1) The ClusterExtension CR defines a service account to deploy and manage the ClusterExtension lifecycle and can be derived using the [document](../howto/dervice-service-account.md). It is specified in the ClusterExtension [yaml](../tutorials/install-extension#L71) while deploying a ClusterExtension.
2) The purpose of the service account specified in the ClusterExtension spec is to manage the cluster extension lifecycle. Its permissions is the cumulative of permissions required for managing the cluster extension lifecycle and the RBAC for the operator bundle.
3) The contents of the operator bundle 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, see https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping
4) The OLMv1 operator-controller generates a service account with the required RBAC for the extension controller based on the contents of the ClusterServiceVersion in much the same way that OLMv0 does. In the ArgoCD example, the [controller service account](https://github.com/argoproj-labs/argocd-operator/blob/da6b8a7e68f71920de9545152714b9066990fc4b/deploy/olm-catalog/argocd-operator/0.6.0/argocd-operator.v0.6.0.clusterserviceversion.yaml#L1124) permissions allow the operator to manage and run the controller logic.
Copy link
Member

Choose a reason for hiding this comment

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

I'm on the fence about how important it is to include bullet (4). It seems that at a conceptual level, but bullet could be left out and the document would stand on its own, such that it describes the concept without delving into implementation specifics.

On the otherhand, concrete examples can be useful to illustrate a concept. Two alternative suggestions:

  1. Re-write this to be more of an example rather than another bullet point.
  2. Going along with (1), is there a place in the docs that we talk about registry+v1 specifics? If so, maybe we insert some details there about how OLMv1 generates service accounts and RBAC? Then we could link there from there.

Maybe we drop bullet (4) for now, and do an example in a follow-up?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updating 4) to an example


Note: The ClusterExtension permissions are not propogated to the deployment. The ClusterExtension service account and the bundle's service accounts have different purposes and naming conflicts between the two service accounts can lead to failure of ClusterExtension deployment.

The ClusterExtension permissions needs to be manually derived based on the details listed above and specified when deploying a ClsuterExtension.