From 664a51fab2e26c61b99ee69692abf88c3d15c36b Mon Sep 17 00:00:00 2001 From: rashmi_kh Date: Tue, 10 Sep 2024 00:37:10 +0530 Subject: [PATCH 01/11] changes to derice minimum service account Signed-off-by: rashmi_kh --- docs/drafts/derive-serviceaccount.md | 358 +++++++++++++++++++++++++++ 1 file changed, 358 insertions(+) create mode 100644 docs/drafts/derive-serviceaccount.md diff --git a/docs/drafts/derive-serviceaccount.md b/docs/drafts/derive-serviceaccount.md new file mode 100644 index 000000000..9623c12e9 --- /dev/null +++ b/docs/drafts/derive-serviceaccount.md @@ -0,0 +1,358 @@ +# Derive minimal ServiceAccount required for ClusterExtension Installation and Management + +OLM v1 security stance (secure by default) + +Adhering to OLM v1's "Secure by Default" tenet, OLM v1 does not have the permissions necessary to install content. This follows the least privilege principle and reduces the chance of a [confused deputy attack](https://en.wikipedia.org/wiki/Confused_deputy_problem). Instead, a ServiceAccount must be provided by users to install and manage content. + +Explain installing a CE requires a Service Account + +OLMv1 does not provide cluster admin privileges by default for installing cluster extensions. It depends on the cluster extension developer to specify the exact permissions required for the management of any specific bundle. A ServiceAccount needs to be explicitly specified for installing and upgrading operators else will face errors when deploying your cluster extension. + +The ServiceAccount is specified in the ClusterExtension manifest as follows: + +```yaml +apiVersion: olm.operatorframework.io/v1alpha1 +kind: ClusterExtension +metadata: + name: argocd +spec: + source: + sourceType: Catalog + catalog: + packageName: argocd-operator + version: 0.6.0 + install: + namespace: argocd + serviceAccount: + name: argocd-installer +``` + +The cluster extension installer will need RBAC in order to be able to assign the controller the RBAC it requires. +In order to derive the minimal RBAC for the installer service account, you must specify the following permissions: +* ClusterRole with all the roles specified in the bundle ClusterServiceVersion. +* ClusterExtension finalizer +* Allow ClusterExtenstion to set blockOwnerDeletion ownerReferences +* create the controller deployment +* create the ClusterResourceDefnitions +* create the other manifest objects +* create the necessary Cluster/Roles for the controller to be able to perform its job. +* get, list, watch, update, patch, delete the specific resources that get created +* update finalizers on the ClusterExtension to be able to set blockOwnerDeletion and ownerReferences + + +The following ClusterRole rules are needed: +# Allow ClusterExtension to set blockOwnerDeletion ownerReferences +- apiGroups: [olm.operatorframework.io] + resources: [clusterextensions/finalizers] + verbs: [update] + resourceNames: [] +# Manage CRDs +- apiGroups: [apiextensions.k8s.io] + resources: [customresourcedefinitions] + verbs: [create, list, watch] +- apiGroups: [apiextensions.k8s.io] + resources: [customresourcedefinitions] + verbs: [get, update, patch, delete] + resourceNames: [, ..., ] +# Manage ClusterRoles +- apiGroups: [rbac.authorization.k8s.io] + resources: [clusterroles] + verbs: [create, list, watch] +- apiGroups: [rbac.authorization.k8s.io] + resources: [clusterroles] + verbs: [get, update, patch, delete] + resourceNames: [, ..., , , ..., ] +# Manage ClusterRoleBindings +- apiGroups: [rbac.authorization.k8s.io] + resources: [clusterrolebindings] + verbs: [create, list, watch] +- apiGroups: [rbac.authorization.k8s.io] + resources: [clusterrolebindings] + verbs: [get, update, patch, delete] + resourceNames: [, ..., , , ..., ] +* Rules defined in the CSV under `.spec.install.clusterPermissions` and `.spec.install.permissions` +* Rules to manage any other cluster-scoped resources shipped with the bundle +* Rules to manage any other namespace-scoped resources +* Rules to manage the deployment defined in the ClusterServiceVersion +* Rules to manage the service account used for the deployment +- apiGroups: [apps] + resources: [deployments] + verbs: [create, list, watch] + +- apiGroups: [apps] + resources: [deployments] + verbs: [get, update, patch, delete] + resourceNames: [argocd-operator-controller-manager] + +- apiGroups: [""] + resources: [serviceaccounts] + verbs: [create, list, watch] + +- apiGroups: [""] + resources: [serviceaccounts] + verbs: [get, update, patch, delete] + resourceNames: [argocd-operator-controller-manager] +``` + +Below is an example of the argocd installer with the necessary RBAC to deploy the ArgoCD ClusterExtension: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: argocd-installer-clusterrole +rules: +# Allow ClusterExtension to set blockOwnerDeletion ownerReferences +- apiGroups: [olm.operatorframework.io] + resources: [clusterextensions/finalizers] + verbs: [update] + resourceNames: [argocd] +# Manage ArgoCD CRDs +- apiGroups: [apiextensions.k8s.io] + resources: [customresourcedefinitions] + verbs: [create] +- apiGroups: [apiextensions.k8s.io] + resources: [customresourcedefinitions] + verbs: [get, list, watch, update, patch, delete] + resourceNames: + - appprojects.argoproj.io + - argocds.argoproj.io + - applications.argoproj.io + - argocdexports.argoproj.io + - applicationsets.argoproj.io +# Manage ArgoCD ClusterRoles and ClusterRoleBindings +- apiGroups: [rbac.authorization.k8s.io] + resources: [clusterroles] + verbs: [create] +- apiGroups: [rbac.authorization.k8s.io] + resources: [clusterroles] + verbs: [get, list, watch, update, patch, delete] + resourceNames: + - argocd-operator.v0-1dhiybrldl1gyksid1dk2dqjsc72psdybc7iyvse5gpx + - argocd-operator-metrics-reader + - argocd-operator.v0-22gmilmgp91wu25is5i2ec598hni8owq3l71bbkl7iz3 +- apiGroups: [rbac.authorization.k8s.io] + resources: [clusterrolebindings] + verbs: [create] +- apiGroups: [rbac.authorization.k8s.io] + resources: [clusterrolebindings] + verbs: [get, list, watch, update, patch, delete] + resourceNames: + - argocd-operator.v0-1dhiybrldl1gyksid1dk2dqjsc72psdybc7iyvse5gpx + - argocd-operator.v0-22gmilmgp91wu25is5i2ec598hni8owq3l71bbkl7iz3 +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: argocd-installer-rbac-binding +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: argocd-installer-rbac-clusterrole +subjects: +- kind: ServiceAccount + name: argocd-installer + namespace: argocd +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: argocd-installer-rbac-clusterrole +rules: +# ArgoCD's operator requires the following permissions, which means the +# installer also needs them in order to create ArgoCD's RBAC objects. +- apiGroups: [""] + resources: [configmaps] + verbs: ['*'] +- apiGroups: [""] + resources: [endpoints] + verbs: ['*'] +- apiGroups: [""] + resources: [events] + verbs: ['*'] +- apiGroups: [""] + resources: [namespaces] + verbs: ['*'] +- apiGroups: [""] + resources: [persistentvolumeclaims] + verbs: ['*'] +- apiGroups: [""] + resources: [pods] + verbs: ['*', get] +- apiGroups: [""] + resources: [pods/log] + verbs: [get] +- apiGroups: [""] + resources: [secrets] + verbs: ['*'] +- apiGroups: [""] + resources: [serviceaccounts] + verbs: ['*'] +- apiGroups: [""] + resources: [services] + verbs: ['*'] +- apiGroups: [""] + resources: [services/finalizers] + verbs: ['*'] +- apiGroups: [apps] + resources: [daemonsets] + verbs: ['*'] +- apiGroups: [apps] + resources: [deployments] + verbs: ['*'] +- apiGroups: [apps] + resources: [deployments/finalizers] + resourceNames: [argocd-operator] + verbs: [update] +- apiGroups: [apps] + resources: [replicasets] + verbs: ['*'] +- apiGroups: [apps] + resources: [statefulsets] + verbs: ['*'] +- apiGroups: [apps.openshift.io] + resources: [deploymentconfigs] + verbs: ['*'] +- apiGroups: [argoproj.io] + resources: [applications] + verbs: ['*'] +- apiGroups: [argoproj.io] + resources: [appprojects] + verbs: ['*'] +- apiGroups: [argoproj.io] + resources: [argocdexports] + verbs: ['*'] +- apiGroups: [argoproj.io] + resources: [argocdexports/finalizers] + verbs: ['*'] +- apiGroups: [argoproj.io] + resources: [argocdexports/status] + verbs: ['*'] +- apiGroups: [argoproj.io] + resources: [argocds] + verbs: ['*'] +- apiGroups: [argoproj.io] + resources: [argocds/finalizers] + verbs: ['*'] +- apiGroups: [argoproj.io] + resources: [argocds/status] + verbs: ['*'] +- apiGroups: [authentication.k8s.io] + resources: [tokenreviews] + verbs: [create] +- apiGroups: [authorization.k8s.io] + resources: [subjectaccessreviews] + verbs: [create] +- apiGroups: [autoscaling] + resources: [horizontalpodautoscalers] + verbs: ['*'] +- apiGroups: [batch] + resources: [cronjobs] + verbs: ['*'] +- apiGroups: [batch] + resources: [jobs] + verbs: ['*'] +- apiGroups: [config.openshift.io] + resources: [clusterversions] + verbs: [get, list, watch] +- apiGroups: [monitoring.coreos.com] + resources: [prometheuses] + verbs: ['*'] +- apiGroups: [monitoring.coreos.com] + resources: [servicemonitors] + verbs: ['*'] +- apiGroups: [networking.k8s.io] + resources: [ingresses] + verbs: ['*'] +- apiGroups: [oauth.openshift.io] + resources: [oauthclients] + verbs: [create, delete, get, list, patch, update, watch] +- apiGroups: [rbac.authorization.k8s.io] + resources: ['*'] + verbs: ['*'] +- apiGroups: [rbac.authorization.k8s.io] + resources: [clusterrolebindings] + verbs: ['*'] +- apiGroups: [rbac.authorization.k8s.io] + resources: [clusterroles] + verbs: ['*'] +- apiGroups: [route.openshift.io] + resources: [routes] + verbs: ['*'] +- apiGroups: [route.openshift.io] + resources: [routes/custom-host] + verbs: ['*'] +- apiGroups: [template.openshift.io] + resources: [templateconfigs] + verbs: ['*'] +- apiGroups: [template.openshift.io] + resources: [templateinstances] + verbs: ['*'] +- apiGroups: [template.openshift.io] + resources: [templates] + verbs: ['*'] +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + name: argocd-installer-role + namespace: argocd +rules: +- apiGroups: [""] + resources: [serviceaccounts] + verbs: [create] +- apiGroups: [""] + resources: [serviceaccounts] + verbs: [get, list, watch, update, patch, delete] + resourceNames: [argocd-operator-controller-manager] +- apiGroups: [""] + resources: [configmaps] + verbs: [create] +- apiGroups: [""] + resources: [configmaps] + verbs: [get, list, watch, update, patch, delete] + resourceNames: [argocd-operator-manager-config] +- apiGroups: [""] + resources: [services] + verbs: [create] +- apiGroups: [""] + resources: [services] + verbs: [get, list, watch, update, patch, delete] + resourceNames: [argocd-operator-controller-manager-metrics-service] +- apiGroups: [apps] + resources: [deployments] + verbs: [create] +- apiGroups: [apps] + resources: [deployments] + verbs: [get, list, watch, update, patch, delete] + resourceNames: [argocd-operator-controller-manager] +``` + +# Creation of ClusterRoleBinding using the cluster-admin ClusterRole in non-production environments + +```yaml +# Create ClusterRole +kubectl apply -f - < Date: Tue, 10 Sep 2024 00:47:55 +0530 Subject: [PATCH 02/11] remove headers Signed-off-by: rashmi_kh --- docs/drafts/derive-serviceaccount.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/docs/drafts/derive-serviceaccount.md b/docs/drafts/derive-serviceaccount.md index 9623c12e9..e349ec131 100644 --- a/docs/drafts/derive-serviceaccount.md +++ b/docs/drafts/derive-serviceaccount.md @@ -41,12 +41,15 @@ In order to derive the minimal RBAC for the installer service account, you must The following ClusterRole rules are needed: -# Allow ClusterExtension to set blockOwnerDeletion ownerReferences +* Allow ClusterExtension to set blockOwnerDeletion ownerReferences + - apiGroups: [olm.operatorframework.io] resources: [clusterextensions/finalizers] verbs: [update] resourceNames: [] -# Manage CRDs + +* Manage CRDs + - apiGroups: [apiextensions.k8s.io] resources: [customresourcedefinitions] verbs: [create, list, watch] @@ -54,7 +57,9 @@ The following ClusterRole rules are needed: resources: [customresourcedefinitions] verbs: [get, update, patch, delete] resourceNames: [, ..., ] -# Manage ClusterRoles + +* Manage ClusterRoles + - apiGroups: [rbac.authorization.k8s.io] resources: [clusterroles] verbs: [create, list, watch] @@ -62,7 +67,9 @@ The following ClusterRole rules are needed: resources: [clusterroles] verbs: [get, update, patch, delete] resourceNames: [, ..., , , ..., ] -# Manage ClusterRoleBindings + +* Manage ClusterRoleBindings + - apiGroups: [rbac.authorization.k8s.io] resources: [clusterrolebindings] verbs: [create, list, watch] @@ -70,11 +77,13 @@ The following ClusterRole rules are needed: resources: [clusterrolebindings] verbs: [get, update, patch, delete] resourceNames: [, ..., , , ..., ] + * Rules defined in the CSV under `.spec.install.clusterPermissions` and `.spec.install.permissions` * Rules to manage any other cluster-scoped resources shipped with the bundle * Rules to manage any other namespace-scoped resources * Rules to manage the deployment defined in the ClusterServiceVersion * Rules to manage the service account used for the deployment + - apiGroups: [apps] resources: [deployments] verbs: [create, list, watch] @@ -92,7 +101,7 @@ The following ClusterRole rules are needed: resources: [serviceaccounts] verbs: [get, update, patch, delete] resourceNames: [argocd-operator-controller-manager] -``` + Below is an example of the argocd installer with the necessary RBAC to deploy the ArgoCD ClusterExtension: From 24d93f109cea5cd46f7a8e692f263835ff44f733 Mon Sep 17 00:00:00 2001 From: rashmi_kh Date: Tue, 10 Sep 2024 15:33:44 +0530 Subject: [PATCH 03/11] add details about registry+v1 support --- docs/drafts/derive-serviceaccount.md | 77 +++++++++++++++++----------- 1 file changed, 46 insertions(+), 31 deletions(-) diff --git a/docs/drafts/derive-serviceaccount.md b/docs/drafts/derive-serviceaccount.md index e349ec131..cd4088a4a 100644 --- a/docs/drafts/derive-serviceaccount.md +++ b/docs/drafts/derive-serviceaccount.md @@ -1,14 +1,8 @@ # Derive minimal ServiceAccount required for ClusterExtension Installation and Management -OLM v1 security stance (secure by default) +OLMv1 does not provide cluster admin privileges by default for installing cluster extensions.This means that the installation process will require a service account with sufficient privileges to install the bundle. It depends on the cluster extension developer to specify the exact permissions required for the management of any specific bundle. A Service Account needs to be explicitly specified for installing and upgrading operators else will face errors when deploying your cluster extension. -Adhering to OLM v1's "Secure by Default" tenet, OLM v1 does not have the permissions necessary to install content. This follows the least privilege principle and reduces the chance of a [confused deputy attack](https://en.wikipedia.org/wiki/Confused_deputy_problem). Instead, a ServiceAccount must be provided by users to install and manage content. - -Explain installing a CE requires a Service Account - -OLMv1 does not provide cluster admin privileges by default for installing cluster extensions. It depends on the cluster extension developer to specify the exact permissions required for the management of any specific bundle. A ServiceAccount needs to be explicitly specified for installing and upgrading operators else will face errors when deploying your cluster extension. - -The ServiceAccount is specified in the ClusterExtension manifest as follows: +The Service Account is specified in the ClusterExtension manifest as shown below: ```yaml apiVersion: olm.operatorframework.io/v1alpha1 @@ -27,20 +21,31 @@ spec: name: argocd-installer ``` -The cluster extension installer will need RBAC in order to be able to assign the controller the RBAC it requires. -In order to derive the minimal RBAC for the installer service account, you must specify the following permissions: -* ClusterRole with all the roles specified in the bundle ClusterServiceVersion. -* ClusterExtension finalizer -* Allow ClusterExtenstion to set blockOwnerDeletion ownerReferences -* create the controller deployment -* create the ClusterResourceDefnitions -* create the other manifest objects -* create the necessary Cluster/Roles for the controller to be able to perform its job. -* get, list, watch, update, patch, delete the specific resources that get created -* update finalizers on the ClusterExtension to be able to set blockOwnerDeletion and ownerReferences +The initial stable version (v1.0.0) only supports FBC catalogs containing registry+v1 bundles. OLMv1 will not support all OLMv0 content. OLMv1 will only support bundles that meet the following criteria: +* AllNamespaces install mode is enabled +* No dependencies on other packages or GVKs +* No webhooks +* Does not make use of the OperatorConditions API + +### Required RBAC +The cluster extension installer should have the prerequisite permissions in order to be able to assign the controller the RBAC it requires. In order to derive the minimal RBAC for the installer service account, you must specify the following permissions: + +* ClusterRole with all the roles specified in the bundle ClusterServiceVersion. This includes all the + rules defined in the CSV under `.spec.install.clusterPermissions` and `.spec.install.permissions` +* ClusterRole to create and manage CustomResourceDefinitions +* Update finalizers on the ClusterExtension to be able to set blockOwnerDeletion and ownerReferences +* Permissions to create the controller deployment, this corresponds to the rules to manage the + deployment defined in the ClusterServiceVersion +* Permissions to create the other manifest objects, rules to manage any other cluster-scoped resources + shipped with the bundle +* Rules to manage any other namespace-scoped resources +* Permissions to create the necessary roles and rolebindings for the controller to be able to perform its job +* Get, list, watch, update, patch, delete the specific resources that get created + + +### Below are snippets of the ClusterRole rule definitions: -The following ClusterRole rules are needed: * Allow ClusterExtension to set blockOwnerDeletion ownerReferences - apiGroups: [olm.operatorframework.io] @@ -48,7 +53,7 @@ The following ClusterRole rules are needed: verbs: [update] resourceNames: [] -* Manage CRDs +* Manage Custom Resource Definitions - apiGroups: [apiextensions.k8s.io] resources: [customresourcedefinitions] @@ -58,7 +63,7 @@ The following ClusterRole rules are needed: verbs: [get, update, patch, delete] resourceNames: [, ..., ] -* Manage ClusterRoles +* Manage Cluster Roles - apiGroups: [rbac.authorization.k8s.io] resources: [clusterroles] @@ -68,7 +73,7 @@ The following ClusterRole rules are needed: verbs: [get, update, patch, delete] resourceNames: [, ..., , , ..., ] -* Manage ClusterRoleBindings +* Manage Cluster Role Bindings - apiGroups: [rbac.authorization.k8s.io] resources: [clusterrolebindings] @@ -78,11 +83,7 @@ The following ClusterRole rules are needed: verbs: [get, update, patch, delete] resourceNames: [, ..., , , ..., ] -* Rules defined in the CSV under `.spec.install.clusterPermissions` and `.spec.install.permissions` -* Rules to manage any other cluster-scoped resources shipped with the bundle -* Rules to manage any other namespace-scoped resources -* Rules to manage the deployment defined in the ClusterServiceVersion -* Rules to manage the service account used for the deployment +* Manage deployments - apiGroups: [apps] resources: [deployments] @@ -93,6 +94,9 @@ The following ClusterRole rules are needed: verbs: [get, update, patch, delete] resourceNames: [argocd-operator-controller-manager] + +* Manage service accounts used for the deployment + - apiGroups: [""] resources: [serviceaccounts] verbs: [create, list, watch] @@ -105,7 +109,7 @@ The following ClusterRole rules are needed: Below is an example of the argocd installer with the necessary RBAC to deploy the ArgoCD ClusterExtension: -```yaml +???+ note apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: @@ -337,7 +341,18 @@ rules: resourceNames: [argocd-operator-controller-manager] ``` -# Creation of ClusterRoleBinding using the cluster-admin ClusterRole in non-production environments +### Manual process for minimal RBAC creation + +There are no production tools available to help you understand the precise RBAC required for your cluster extensions. However, if you want to figure this manually you can try the below: + +* Create all the intial rbac and then iterate over the ClusterExtention failures, examining conditions and updating the RBAC to include the generated cluster role names (name will be in the failure condition). +Install the ClusterExtension, read the failure condition, update installer RBAC and iterate until you are out of errors +* You can get the bundle image, unpacking the same and inspect the manifests to figure out the required permissions. +* The `oc` cli-tool creates cluster roles with a hash in their name, query the newly created ClusterRole names, then reduce the installer RBAC scope to just the ClusterRoles needed (inc. the generated ones). You can achieve this by allowing the installer to get, list, watch and update any cluster roles. + + + +### Creation of ClusterRoleBinding using the cluster-admin ClusterRole in non-production environments ```yaml # Create ClusterRole @@ -356,7 +371,7 @@ subjects: namespace: my-cluster-extension-namespace EOF -``` +```sh kubectl create clusterrolebinding my-cluster-extension-installer-role-binding \ --clusterrole=cluster-admin \ --serviceaccount=my-cluster-extension-namespace:my-cluster-installer-service-account From fdf7e9d5551964b712eb0f085d5bdf23ccddf1e0 Mon Sep 17 00:00:00 2001 From: rashmi_kh Date: Tue, 10 Sep 2024 15:37:06 +0530 Subject: [PATCH 04/11] render yml correctly Signed-off-by: rashmi_kh --- docs/drafts/derive-serviceaccount.md | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/docs/drafts/derive-serviceaccount.md b/docs/drafts/derive-serviceaccount.md index cd4088a4a..62cb1305d 100644 --- a/docs/drafts/derive-serviceaccount.md +++ b/docs/drafts/derive-serviceaccount.md @@ -48,13 +48,16 @@ The cluster extension installer should have the prerequisite permissions in orde * Allow ClusterExtension to set blockOwnerDeletion ownerReferences +```yaml - apiGroups: [olm.operatorframework.io] resources: [clusterextensions/finalizers] verbs: [update] resourceNames: [] +``` * Manage Custom Resource Definitions +```yaml - apiGroups: [apiextensions.k8s.io] resources: [customresourcedefinitions] verbs: [create, list, watch] @@ -62,9 +65,11 @@ The cluster extension installer should have the prerequisite permissions in orde resources: [customresourcedefinitions] verbs: [get, update, patch, delete] resourceNames: [, ..., ] +``` * Manage Cluster Roles +```yaml - apiGroups: [rbac.authorization.k8s.io] resources: [clusterroles] verbs: [create, list, watch] @@ -72,9 +77,11 @@ The cluster extension installer should have the prerequisite permissions in orde resources: [clusterroles] verbs: [get, update, patch, delete] resourceNames: [, ..., , , ..., ] +``` * Manage Cluster Role Bindings +```yaml - apiGroups: [rbac.authorization.k8s.io] resources: [clusterrolebindings] verbs: [create, list, watch] @@ -82,9 +89,11 @@ The cluster extension installer should have the prerequisite permissions in orde resources: [clusterrolebindings] verbs: [get, update, patch, delete] resourceNames: [, ..., , , ..., ] +``` * Manage deployments +```yaml - apiGroups: [apps] resources: [deployments] verbs: [create, list, watch] @@ -93,10 +102,11 @@ The cluster extension installer should have the prerequisite permissions in orde resources: [deployments] verbs: [get, update, patch, delete] resourceNames: [argocd-operator-controller-manager] - +``` * Manage service accounts used for the deployment - + +```yaml - apiGroups: [""] resources: [serviceaccounts] verbs: [create, list, watch] @@ -105,11 +115,12 @@ The cluster extension installer should have the prerequisite permissions in orde resources: [serviceaccounts] verbs: [get, update, patch, delete] resourceNames: [argocd-operator-controller-manager] - +``` Below is an example of the argocd installer with the necessary RBAC to deploy the ArgoCD ClusterExtension: ???+ note +```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: From ccfd9a9ddf9d2fbcacaf56045d792a418aae32fe Mon Sep 17 00:00:00 2001 From: rashmi_kh Date: Wed, 16 Oct 2024 11:53:10 +0530 Subject: [PATCH 05/11] create doc for olmv1 permission model Signed-off-by: rashmi_kh --- docs/concepts/permission-model.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 docs/concepts/permission-model.md diff --git a/docs/concepts/permission-model.md b/docs/concepts/permission-model.md new file mode 100644 index 000000000..5a9483417 --- /dev/null +++ b/docs/concepts/permission-model.md @@ -0,0 +1,15 @@ +#### OLMv1 Permission Model + +Here we aim to describe the OLMv1 permission model in terms of RBAC defined for the ClusterExtension and RBAC contained in the operator bundle ClusterServiceVersion. + +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. + +For registry+v1 bundles, the deployment's service account is separate and use for managing the controller logic. Its RBAC is derived purely from the RBAC that is defined in the CSV. +The ClusterExtension service account manages the lifecycle of the bundle contents and requires RBAC that allows it to manage that lifecycle. The ClusterExtension service account needs permissions to manage the manifests that are defined by the bundle. + +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 +See https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping + +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. \ No newline at end of file From c40dce641e91dc4746238a6569e0a210fa489eb9 Mon Sep 17 00:00:00 2001 From: Rashmi Khanna Date: Wed, 16 Oct 2024 11:56:01 +0530 Subject: [PATCH 06/11] Delete docs/drafts directory --- docs/drafts/derive-serviceaccount.md | 393 --------------------------- 1 file changed, 393 deletions(-) delete mode 100644 docs/drafts/derive-serviceaccount.md diff --git a/docs/drafts/derive-serviceaccount.md b/docs/drafts/derive-serviceaccount.md deleted file mode 100644 index 62cb1305d..000000000 --- a/docs/drafts/derive-serviceaccount.md +++ /dev/null @@ -1,393 +0,0 @@ -# Derive minimal ServiceAccount required for ClusterExtension Installation and Management - -OLMv1 does not provide cluster admin privileges by default for installing cluster extensions.This means that the installation process will require a service account with sufficient privileges to install the bundle. It depends on the cluster extension developer to specify the exact permissions required for the management of any specific bundle. A Service Account needs to be explicitly specified for installing and upgrading operators else will face errors when deploying your cluster extension. - -The Service Account is specified in the ClusterExtension manifest as shown below: - -```yaml -apiVersion: olm.operatorframework.io/v1alpha1 -kind: ClusterExtension -metadata: - name: argocd -spec: - source: - sourceType: Catalog - catalog: - packageName: argocd-operator - version: 0.6.0 - install: - namespace: argocd - serviceAccount: - name: argocd-installer -``` - -The initial stable version (v1.0.0) only supports FBC catalogs containing registry+v1 bundles. OLMv1 will not support all OLMv0 content. OLMv1 will only support bundles that meet the following criteria: -* AllNamespaces install mode is enabled -* No dependencies on other packages or GVKs -* No webhooks -* Does not make use of the OperatorConditions API - -### Required RBAC - -The cluster extension installer should have the prerequisite permissions in order to be able to assign the controller the RBAC it requires. In order to derive the minimal RBAC for the installer service account, you must specify the following permissions: - -* ClusterRole with all the roles specified in the bundle ClusterServiceVersion. This includes all the - rules defined in the CSV under `.spec.install.clusterPermissions` and `.spec.install.permissions` -* ClusterRole to create and manage CustomResourceDefinitions -* Update finalizers on the ClusterExtension to be able to set blockOwnerDeletion and ownerReferences -* Permissions to create the controller deployment, this corresponds to the rules to manage the - deployment defined in the ClusterServiceVersion -* Permissions to create the other manifest objects, rules to manage any other cluster-scoped resources - shipped with the bundle -* Rules to manage any other namespace-scoped resources -* Permissions to create the necessary roles and rolebindings for the controller to be able to perform its job -* Get, list, watch, update, patch, delete the specific resources that get created - - -### Below are snippets of the ClusterRole rule definitions: - -* Allow ClusterExtension to set blockOwnerDeletion ownerReferences - -```yaml -- apiGroups: [olm.operatorframework.io] - resources: [clusterextensions/finalizers] - verbs: [update] - resourceNames: [] -``` - -* Manage Custom Resource Definitions - -```yaml -- apiGroups: [apiextensions.k8s.io] - resources: [customresourcedefinitions] - verbs: [create, list, watch] -- apiGroups: [apiextensions.k8s.io] - resources: [customresourcedefinitions] - verbs: [get, update, patch, delete] - resourceNames: [, ..., ] -``` - -* Manage Cluster Roles - -```yaml -- apiGroups: [rbac.authorization.k8s.io] - resources: [clusterroles] - verbs: [create, list, watch] -- apiGroups: [rbac.authorization.k8s.io] - resources: [clusterroles] - verbs: [get, update, patch, delete] - resourceNames: [, ..., , , ..., ] -``` - -* Manage Cluster Role Bindings - -```yaml -- apiGroups: [rbac.authorization.k8s.io] - resources: [clusterrolebindings] - verbs: [create, list, watch] -- apiGroups: [rbac.authorization.k8s.io] - resources: [clusterrolebindings] - verbs: [get, update, patch, delete] - resourceNames: [, ..., , , ..., ] -``` - -* Manage deployments - -```yaml -- apiGroups: [apps] - resources: [deployments] - verbs: [create, list, watch] - -- apiGroups: [apps] - resources: [deployments] - verbs: [get, update, patch, delete] - resourceNames: [argocd-operator-controller-manager] -``` - -* Manage service accounts used for the deployment - -```yaml -- apiGroups: [""] - resources: [serviceaccounts] - verbs: [create, list, watch] - -- apiGroups: [""] - resources: [serviceaccounts] - verbs: [get, update, patch, delete] - resourceNames: [argocd-operator-controller-manager] -``` - -Below is an example of the argocd installer with the necessary RBAC to deploy the ArgoCD ClusterExtension: - -???+ note -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRole -metadata: - name: argocd-installer-clusterrole -rules: -# Allow ClusterExtension to set blockOwnerDeletion ownerReferences -- apiGroups: [olm.operatorframework.io] - resources: [clusterextensions/finalizers] - verbs: [update] - resourceNames: [argocd] -# Manage ArgoCD CRDs -- apiGroups: [apiextensions.k8s.io] - resources: [customresourcedefinitions] - verbs: [create] -- apiGroups: [apiextensions.k8s.io] - resources: [customresourcedefinitions] - verbs: [get, list, watch, update, patch, delete] - resourceNames: - - appprojects.argoproj.io - - argocds.argoproj.io - - applications.argoproj.io - - argocdexports.argoproj.io - - applicationsets.argoproj.io -# Manage ArgoCD ClusterRoles and ClusterRoleBindings -- apiGroups: [rbac.authorization.k8s.io] - resources: [clusterroles] - verbs: [create] -- apiGroups: [rbac.authorization.k8s.io] - resources: [clusterroles] - verbs: [get, list, watch, update, patch, delete] - resourceNames: - - argocd-operator.v0-1dhiybrldl1gyksid1dk2dqjsc72psdybc7iyvse5gpx - - argocd-operator-metrics-reader - - argocd-operator.v0-22gmilmgp91wu25is5i2ec598hni8owq3l71bbkl7iz3 -- apiGroups: [rbac.authorization.k8s.io] - resources: [clusterrolebindings] - verbs: [create] -- apiGroups: [rbac.authorization.k8s.io] - resources: [clusterrolebindings] - verbs: [get, list, watch, update, patch, delete] - resourceNames: - - argocd-operator.v0-1dhiybrldl1gyksid1dk2dqjsc72psdybc7iyvse5gpx - - argocd-operator.v0-22gmilmgp91wu25is5i2ec598hni8owq3l71bbkl7iz3 ---- -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRoleBinding -metadata: - name: argocd-installer-rbac-binding -roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: argocd-installer-rbac-clusterrole -subjects: -- kind: ServiceAccount - name: argocd-installer - namespace: argocd ---- -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRole -metadata: - name: argocd-installer-rbac-clusterrole -rules: -# ArgoCD's operator requires the following permissions, which means the -# installer also needs them in order to create ArgoCD's RBAC objects. -- apiGroups: [""] - resources: [configmaps] - verbs: ['*'] -- apiGroups: [""] - resources: [endpoints] - verbs: ['*'] -- apiGroups: [""] - resources: [events] - verbs: ['*'] -- apiGroups: [""] - resources: [namespaces] - verbs: ['*'] -- apiGroups: [""] - resources: [persistentvolumeclaims] - verbs: ['*'] -- apiGroups: [""] - resources: [pods] - verbs: ['*', get] -- apiGroups: [""] - resources: [pods/log] - verbs: [get] -- apiGroups: [""] - resources: [secrets] - verbs: ['*'] -- apiGroups: [""] - resources: [serviceaccounts] - verbs: ['*'] -- apiGroups: [""] - resources: [services] - verbs: ['*'] -- apiGroups: [""] - resources: [services/finalizers] - verbs: ['*'] -- apiGroups: [apps] - resources: [daemonsets] - verbs: ['*'] -- apiGroups: [apps] - resources: [deployments] - verbs: ['*'] -- apiGroups: [apps] - resources: [deployments/finalizers] - resourceNames: [argocd-operator] - verbs: [update] -- apiGroups: [apps] - resources: [replicasets] - verbs: ['*'] -- apiGroups: [apps] - resources: [statefulsets] - verbs: ['*'] -- apiGroups: [apps.openshift.io] - resources: [deploymentconfigs] - verbs: ['*'] -- apiGroups: [argoproj.io] - resources: [applications] - verbs: ['*'] -- apiGroups: [argoproj.io] - resources: [appprojects] - verbs: ['*'] -- apiGroups: [argoproj.io] - resources: [argocdexports] - verbs: ['*'] -- apiGroups: [argoproj.io] - resources: [argocdexports/finalizers] - verbs: ['*'] -- apiGroups: [argoproj.io] - resources: [argocdexports/status] - verbs: ['*'] -- apiGroups: [argoproj.io] - resources: [argocds] - verbs: ['*'] -- apiGroups: [argoproj.io] - resources: [argocds/finalizers] - verbs: ['*'] -- apiGroups: [argoproj.io] - resources: [argocds/status] - verbs: ['*'] -- apiGroups: [authentication.k8s.io] - resources: [tokenreviews] - verbs: [create] -- apiGroups: [authorization.k8s.io] - resources: [subjectaccessreviews] - verbs: [create] -- apiGroups: [autoscaling] - resources: [horizontalpodautoscalers] - verbs: ['*'] -- apiGroups: [batch] - resources: [cronjobs] - verbs: ['*'] -- apiGroups: [batch] - resources: [jobs] - verbs: ['*'] -- apiGroups: [config.openshift.io] - resources: [clusterversions] - verbs: [get, list, watch] -- apiGroups: [monitoring.coreos.com] - resources: [prometheuses] - verbs: ['*'] -- apiGroups: [monitoring.coreos.com] - resources: [servicemonitors] - verbs: ['*'] -- apiGroups: [networking.k8s.io] - resources: [ingresses] - verbs: ['*'] -- apiGroups: [oauth.openshift.io] - resources: [oauthclients] - verbs: [create, delete, get, list, patch, update, watch] -- apiGroups: [rbac.authorization.k8s.io] - resources: ['*'] - verbs: ['*'] -- apiGroups: [rbac.authorization.k8s.io] - resources: [clusterrolebindings] - verbs: ['*'] -- apiGroups: [rbac.authorization.k8s.io] - resources: [clusterroles] - verbs: ['*'] -- apiGroups: [route.openshift.io] - resources: [routes] - verbs: ['*'] -- apiGroups: [route.openshift.io] - resources: [routes/custom-host] - verbs: ['*'] -- apiGroups: [template.openshift.io] - resources: [templateconfigs] - verbs: ['*'] -- apiGroups: [template.openshift.io] - resources: [templateinstances] - verbs: ['*'] -- apiGroups: [template.openshift.io] - resources: [templates] - verbs: ['*'] ---- -apiVersion: rbac.authorization.k8s.io/v1 -kind: Role -metadata: - name: argocd-installer-role - namespace: argocd -rules: -- apiGroups: [""] - resources: [serviceaccounts] - verbs: [create] -- apiGroups: [""] - resources: [serviceaccounts] - verbs: [get, list, watch, update, patch, delete] - resourceNames: [argocd-operator-controller-manager] -- apiGroups: [""] - resources: [configmaps] - verbs: [create] -- apiGroups: [""] - resources: [configmaps] - verbs: [get, list, watch, update, patch, delete] - resourceNames: [argocd-operator-manager-config] -- apiGroups: [""] - resources: [services] - verbs: [create] -- apiGroups: [""] - resources: [services] - verbs: [get, list, watch, update, patch, delete] - resourceNames: [argocd-operator-controller-manager-metrics-service] -- apiGroups: [apps] - resources: [deployments] - verbs: [create] -- apiGroups: [apps] - resources: [deployments] - verbs: [get, list, watch, update, patch, delete] - resourceNames: [argocd-operator-controller-manager] -``` - -### Manual process for minimal RBAC creation - -There are no production tools available to help you understand the precise RBAC required for your cluster extensions. However, if you want to figure this manually you can try the below: - -* Create all the intial rbac and then iterate over the ClusterExtention failures, examining conditions and updating the RBAC to include the generated cluster role names (name will be in the failure condition). -Install the ClusterExtension, read the failure condition, update installer RBAC and iterate until you are out of errors -* You can get the bundle image, unpacking the same and inspect the manifests to figure out the required permissions. -* The `oc` cli-tool creates cluster roles with a hash in their name, query the newly created ClusterRole names, then reduce the installer RBAC scope to just the ClusterRoles needed (inc. the generated ones). You can achieve this by allowing the installer to get, list, watch and update any cluster roles. - - - -### Creation of ClusterRoleBinding using the cluster-admin ClusterRole in non-production environments - -```yaml -# Create ClusterRole -kubectl apply -f - < Date: Thu, 17 Oct 2024 13:38:54 +0530 Subject: [PATCH 07/11] Update permission-model.md --- docs/concepts/permission-model.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/docs/concepts/permission-model.md b/docs/concepts/permission-model.md index 5a9483417..81590a023 100644 --- a/docs/concepts/permission-model.md +++ b/docs/concepts/permission-model.md @@ -1,15 +1,13 @@ #### OLMv1 Permission Model -Here we aim to describe the OLMv1 permission model in terms of RBAC defined for the ClusterExtension and RBAC contained in the operator bundle ClusterServiceVersion. +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. -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. -For registry+v1 bundles, the deployment's service account is separate and use for managing the controller logic. Its RBAC is derived purely from the RBAC that is defined in the CSV. -The ClusterExtension service account manages the lifecycle of the bundle contents and requires RBAC that allows it to manage that lifecycle. The ClusterExtension service account needs permissions to manage the manifests that are defined by the bundle. - -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 +1) The purpose of the service account specified in the ClusterExtension spec, which is to manage everything in (2) below. +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 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 -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. \ No newline at end of file +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. From 7bcdd89ac2353c3de97be1ec2b8b3aa0fc677445 Mon Sep 17 00:00:00 2001 From: rashmi_kh Date: Thu, 17 Oct 2024 19:10:30 +0530 Subject: [PATCH 08/11] update permission models with link Signed-off-by: rashmi_kh --- docs/concepts/permission-model.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/concepts/permission-model.md b/docs/concepts/permission-model.md index 81590a023..3cf8a90be 100644 --- a/docs/concepts/permission-model.md +++ b/docs/concepts/permission-model.md @@ -1,6 +1,6 @@ #### 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. +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 specifies a service account that will be used to manage its bundle contents. The cluster extension service account is a superset of the permissions specified for the service account in the operator bundle. It maintains a distinction with the operator bundle service account. 1) The purpose of the service account specified in the ClusterExtension spec, which is to manage everything in (2) below. @@ -8,6 +8,7 @@ Here we aim to describe the OLMv1 permission model. OLMv1 itself does not have p - the same set of permissions that are defined in the RBAC that it is trying to create. - bind/escalate verbs for RBAC, OR 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 +3) 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. 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. +4) The ClusterExtension CR also 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. -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. +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. From 23223b42573f8b64e93b7986cbc5684e8e03d7bf Mon Sep 17 00:00:00 2001 From: rashmi_kh Date: Thu, 17 Oct 2024 19:14:42 +0530 Subject: [PATCH 09/11] add space Signed-off-by: rashmi_kh --- docs/concepts/permission-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/permission-model.md b/docs/concepts/permission-model.md index 3cf8a90be..ab79cbe1b 100644 --- a/docs/concepts/permission-model.md +++ b/docs/concepts/permission-model.md @@ -9,6 +9,6 @@ Here we aim to describe the OLMv1 permission model. OLMv1 does not have permissi - bind/escalate verbs for RBAC, OR See https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping 3) 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. 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. -4) The ClusterExtension CR also 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. +4) The ClusterExtension CR also 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. 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. From 65aece4f977b16215f4352cbe5060cbeb3fd23a7 Mon Sep 17 00:00:00 2001 From: rashmi_kh Date: Mon, 21 Oct 2024 19:51:35 +0530 Subject: [PATCH 10/11] add more structure Signed-off-by: rashmi_kh --- docs/concepts/permission-model.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/docs/concepts/permission-model.md b/docs/concepts/permission-model.md index ab79cbe1b..b840546b4 100644 --- a/docs/concepts/permission-model.md +++ b/docs/concepts/permission-model.md @@ -1,14 +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 specifies a service account that will be used to manage its bundle contents. The cluster extension service account is a superset of the permissions specified for the service account in the operator bundle. It maintains a distinction with the operator bundle service account. +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 purpose of the service account specified in the ClusterExtension spec, which is to manage everything in (2) below. -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: +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, OR -See https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping -3) 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. 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. -4) The ClusterExtension CR also 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. +- 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. 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. From 34efe90daa6c5cfb45bc987ccd907c27e7b49656 Mon Sep 17 00:00:00 2001 From: rashmi_kh Date: Fri, 25 Oct 2024 00:09:24 +0530 Subject: [PATCH 11/11] incorporate review comments Signed-off-by: rashmi_kh --- docs/concepts/permission-model.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/docs/concepts/permission-model.md b/docs/concepts/permission-model.md index b840546b4..031879ffc 100644 --- a/docs/concepts/permission-model.md +++ b/docs/concepts/permission-model.md @@ -4,13 +4,11 @@ Here we aim to describe the OLMv1 permission model. OLMv1 does not have permissi 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: +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. +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 maybe included in the extenion bundle. +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: - 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. 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.