|
1 | 1 | #### OLMv1 Permission Model |
2 | 2 |
|
3 | | -> **Deprecated:** The permission model described below is no longer accurate. |
4 | | -> operator-controller now runs with cluster-admin privileges and uses its own ServiceAccount |
5 | | -> for all extension lifecycle operations. The `spec.serviceAccount` field on ClusterExtension |
6 | | -> is deprecated and ignored. |
| 3 | +OLM v1's permission model is built on a simple principle: **operator-controller runs as cluster-admin**, and the security boundary is defined by who can create and modify `ClusterExtension` and `ClusterCatalog` resources. |
7 | 4 |
|
8 | | -Here we aim to describe the OLMv1 permission model. OLMv1 itself does not have cluster-wide admin permissions. Therefore, each cluster extension must specify a service account with sufficient permissions to install and manage it. While this service account is distinct from any service account defined in the bundle, it will need sufficient privileges to create and assign the required RBAC. Therefore, the cluster extension service account's privileges would be a superset of the privileges required by the service account in the bundle. |
| 5 | +#### How It Works |
9 | 6 |
|
10 | | -To understand the permission model, lets see the scope of the the service accounts associated with ClusterExtension deployment: |
| 7 | +1. **operator-controller** runs with `cluster-admin` privileges, giving it full authority to install and manage extension lifecycle resources (CRDs, Deployments, RBAC, etc.) on behalf of `ClusterExtension` objects. |
| 8 | +2. **Security is enforced via RBAC on the OLM APIs themselves.** Only cluster administrators should have `create`, `update`, or `delete` permissions on `ClusterExtension` and `ClusterCatalog` resources. |
| 9 | +3. **Creating a `ClusterExtension` is equivalent to having cluster-admin privileges**, because it instructs operator-controller to install arbitrary workloads and RBAC. Cluster administrators must not grant non-admin users write access to these APIs. |
11 | 10 |
|
12 | | -#### Service Account associated with the ClusterExtension CR |
| 11 | +#### Security Considerations |
13 | 12 |
|
14 | | -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. |
15 | | -2) The purpose of the service account specified in the ClusterExtension spec is to manage the cluster extension lifecycle. Its permissions are the cumulative of the permissions required for managing the cluster extension lifecycle and any RBAC that maybe included in the extension bundle. |
16 | | -3) Since the extension bundle contains its own RBAC, it means the ClusterExtension service account requires either: |
17 | | -- the same set of permissions that are defined in the RBAC that it is trying to create. |
18 | | -- bind/escalate verbs for RBAC, see https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping |
| 13 | +!!! warning |
| 14 | + `ClusterExtension` and `ClusterCatalog` are **cluster-admin-only APIs**. Granting non-admin users |
| 15 | + `create`, `update`, or `delete` access on these resources is equivalent to granting them cluster-admin |
| 16 | + privileges. |
19 | 17 |
|
20 | | -#### Service Account/(s) part of the Extension Bundle |
21 | | -1) The contents of the extension bundle may contain more service accounts and RBAC. |
22 | | -2) The OLMv1 operator-controller creates the service account/(s) defined as part of the extension bundle with the required RBAC for the controller business logic. |
| 18 | +- Cluster admins must audit RBAC to ensure only trusted users can manage `ClusterExtension` and `ClusterCatalog` resources. |
| 19 | +- The rationale for this model is explained in the [Design Decisions](../project/olmv1_design_decisions.md) document. |
23 | 20 |
|
24 | | -##### Example: |
| 21 | +#### Extension Resources |
25 | 22 |
|
26 | | -Lets consider deployment of the ArgoCD operator. The ClusterExtension ClusterResource specifies a service account as part of its spec, usually denoted as the ClusterExtension installer service account. |
27 | | -The ArgoCD operator specifies the `argocd-operator-controller-manager` [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) with necessary RBAC for the bundle resources and OLMv1 creates it as part of this extension bundle deployment. |
28 | | - |
29 | | -The extension bundle CSV contains the [permissions](https://github.com/argoproj-labs/argocd-operator/blob/da6b8a7e68f71920de9545152714b9066990fc4b/deploy/olm-catalog/argocd-operator/0.6.0/argocd-operator.v0.6.0.clusterserviceversion.yaml#L1091) and [cluster permissions](https://github.com/argoproj-labs/argocd-operator/blob/da6b8a7e68f71920de9545152714b9066990fc4b/deploy/olm-catalog/argocd-operator/0.6.0/argocd-operator.v0.6.0.clusterserviceversion.yaml#L872) allow the operator to manage and run the controller logic. These permissions are assigned to the `argocd-operator-controller-manager` service account when the operator bundle is deployed. |
30 | | - |
31 | | -OLM v1 will assign all the RBAC specified in the extension bundle to the above service account. |
32 | | -The ClusterExtension installer service account will need all the RBAC specified for the `argocd-operator-controller-manager` and additional RBAC for deploying the ClusterExtension. |
33 | | - |
34 | | -**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. |
| 23 | +operator-controller installs and manages all resources declared in an extension's bundle, including any ServiceAccounts, RBAC, Deployments, and other Kubernetes objects. These resources are distinct from operator-controller's own service account and are scoped to whatever the bundle declares. |
0 commit comments