You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/project/olmv1_design_decisions.md
+5-7Lines changed: 5 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -178,15 +178,13 @@ However, it should be noted that the purpose of these primitives is not to enabl
178
178
179
179
### Secure access to ClusterExtensions through API access RBAC and ValidatingAdmissionPolicy
180
180
181
-
OLMv1 adopts cluster-admin scope directly. Previously, OLMv1 required cluster administrators to create ServiceAccounts and associated RBAC to enable the installation of ClusterExtensions. The current approach provides the following benefits:
181
+
OLMv1 is a single-tenant system that treats installed extensions as trusted cluster components, consistent with the Kubernetes design assumption that [CRDs and their controllers are trusted cluster extensions](#watched-namespaces-cannot-be-configured-in-a-first-class-api). The operator-controller uses its own cluster-admin service account for all operations.
182
182
183
-
- Eliminates the complexity of difficult-to-determine permissions
184
-
- Removes the UX burden of requiring users to manage ServiceAccounts
185
-
- Enables simpler internal operations for namespace management and content lifecycle
183
+
Because creating or modifying a `ClusterExtension` triggers cluster-admin-level operations, cluster administrators should treat write access to the `ClusterExtension` API as equivalent to granting cluster-admin privileges. To restrict which users may trigger installations, use Kubernetes RBAC on the `ClusterExtension` API; for finer-grained constraints such as limiting which packages, catalogs, namespaces, or upgrade policies a user may specify, pair RBAC with a `ValidatingAdmissionPolicy`. For concrete examples of both approaches, see [Protecting OLMv1 API Access](../howto/how-to-protect-olmv1-api-access.md).
186
184
187
-
> **Note:** The `spec.serviceAccount` field is deprecated and will be removed in a future release. The field is retained in the API for backwards compatibility. The API server still accepts the field, but its value is silently ignored.
188
-
189
-
Because the operator-controller uses its own cluster-admin service account for all operations, cluster administrators should treat the ability to create or modify `ClusterExtension` resources as equivalent to granting cluster-admin privileges, and guard that access accordingly. To restrict which users may trigger installations, use Kubernetes RBAC on the `ClusterExtension` API; for finer-grained constraints such as limiting which packages, catalogs, namespaces, or upgrade policies a user may specify, pair RBAC with a `ValidatingAdmissionPolicy`. For concrete examples of both approaches, see [Protecting OLMv1 API Access](../howto/how-to-protect-olmv1-api-access.md).
185
+
> **Deprecation note:** The `spec.serviceAccount` field is deprecated and will be removed in a future release. The field is retained in the API for backwards compatibility, but its value is silently ignored.
186
+
>
187
+
> Previously, OLMv1 required cluster administrators to bind ServiceAccounts with associated RBAC to scope the permissions available to each ClusterExtension. In practice, this did not provide meaningful security: any user with write access to the ClusterExtension API could reference any existing ServiceAccount in any namespace, including highly-privileged ones. The permission model added UX friction without delivering the isolation and policy guarantees it implied.
190
188
191
189
OLM v1 also uses secure communication protocols between all internal components and between itself and its clients.
0 commit comments