📖 Document OLMv1 permission model #1380
Conversation
Signed-off-by: rashmi_kh <[email protected]>
Signed-off-by: rashmi_kh <[email protected]>
Signed-off-by: rashmi_kh <[email protected]>
Signed-off-by: rashmi_kh <[email protected]>
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1380 +/- ##
==========================================
- Coverage 74.84% 74.73% -0.12%
==========================================
Files 42 42
Lines 2516 3241 +725
==========================================
+ Hits 1883 2422 +539
- Misses 449 646 +197
+ Partials 184 173 -11
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Signed-off-by: rashmi_kh <[email protected]>
Signed-off-by: rashmi_kh <[email protected]>
docs/concepts/permission-model.md
Outdated
| 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. | ||
|
|
||
|
|
||
| 1) The purpose of the service account specified in the ClusterExtension spec, which is to manage everything in (2) below. |
There was a problem hiding this comment.
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
Signed-off-by: rashmi_kh <[email protected]>
docs/concepts/permission-model.md
Outdated
| 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. |
There was a problem hiding this comment.
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:
- Re-write this to be more of an example rather than another bullet point.
- Going along with (1), is there a place in the docs that we talk about
registry+v1specifics? 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?
There was a problem hiding this comment.
updating 4) to an example
Signed-off-by: rashmi_kh <[email protected]>
Signed-off-by: rashmi_kh <[email protected]>
Signed-off-by: rashmi_kh <[email protected]>
|
@perdasilva i have updated the example section, can you have a final look |
e5820ae
Update go version checker (operator-framework#1474) * Handle new files (old version is empty) * Handle the case where .0 patch is added/removed Signed-off-by: Todd Short <[email protected]> sa not found Signed-off-by: rashmi_kh <[email protected]> 📖 Document OLMv1 permission model (operator-framework#1380) * changes to derice minimum service account Signed-off-by: rashmi_kh <[email protected]> * remove headers Signed-off-by: rashmi_kh <[email protected]> * add details about registry+v1 support * render yml correctly Signed-off-by: rashmi_kh <[email protected]> * create doc for olmv1 permission model Signed-off-by: rashmi_kh <[email protected]> * Delete docs/drafts directory * Update permission-model.md * update permission models with link Signed-off-by: rashmi_kh <[email protected]> * add space Signed-off-by: rashmi_kh <[email protected]> * add more structure Signed-off-by: rashmi_kh <[email protected]> * incorporate review comments Signed-off-by: rashmi_kh <[email protected]> * incorporate review comments Signed-off-by: rashmi_kh <[email protected]> * pers review comments-s * example as header-s * update the example Signed-off-by: rashmi_kh <[email protected]> --------- Signed-off-by: rashmi_kh <[email protected]> Delete docs/drafts/derive-serviceaccount.md add custom sa not found Signed-off-by: rashmi_kh <[email protected]>
Description
Document OLMv1 permission model
aims to clarify #1376
Reviewer Checklist