📖 Document OLMv1 permission model

[rashmi43]

Description

Document OLMv1 permission model
aims to clarify #1376

Reviewer Checklist

• API Go Documentation
• Tests: Unit Tests (and E2E Tests, if appropriate)
• Comprehensive Commit Messages
• Links to related GitHub Issue(s)

[netlify]

✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	65aece4
🔍 Latest deploy log	https://app.netlify.com/sites/olmv1/deploys/6716637ca07ea40008303aab
😎 Deploy Preview	https://deploy-preview-1380--olmv1.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 73.12%. Comparing base (b7674d8) to head (65aece4).
Report is 8 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1380      +/-   ##
==========================================
- Coverage   74.84%   73.12%   -1.73%     
==========================================
  Files          42       42              
  Lines        2516     3166     +650     
==========================================
+ Hits         1883     2315     +432     
- Misses        449      663     +214     
- Partials      184      188       +4     

Flag	Coverage Δ
e2e	54.64% <ø> (-2.12%)	⬇️
unit	52.52% <ø> (-0.18%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[perdasilva]

Suggested change

	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.
	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 specify a service account that will be used to manage its bundle contents.

[perdasilva]

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

[joelanford]

Suggested change

	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.
	1) The ClusterExtension CR defines a service account to deploy and manage the ClusterExtension lifecycle and can be derived using the [document](../howto/derive-service-account.md). It is specified in the ClusterExtension [yaml](../tutorials/install-extension#L71) while deploying a ClusterExtension.

[joelanford]

Suggested change

	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.
	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 any RBAC that may be included in the extension bundle.

[joelanford]

Suggested change

	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:
	3) The contents of the extension bundle may contain more service accounts and RBAC. Since the extension bundle contains its own RBAC, it means the ClusterExtension service account requires either:

[joelanford]

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?

[joelanford]

Rather than stating that RBAC needs to be manually derived, I think I would drop this sentence. We already link to the "derive-service-account" doc above. In the future, we'll make this UX better, and I think it will be easier to catch the necessary doc change if we keep the details about deriving a service account in a single place.