Skip to content

Commit ffd0491

Browse files
awgreeneawgreene
committed
Messy wip
1 parent e4a8436 commit ffd0491

File tree

1 file changed

+209
-0
lines changed

1 file changed

+209
-0
lines changed

‎enhancements/rbac-toggle.md

Lines changed: 209 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,209 @@
1+
---
2+
title: rbac-toggle
3+
authors:
4+
- "@awgreene"
5+
reviewers:
6+
- TBD
7+
approvers:
8+
- TBD
9+
creation-date: 2023-05-01
10+
last-updated: 2023-05-01
11+
status: implementable
12+
see-also:
13+
- "/enhancements/this-other-neat-thing.md"
14+
replaces:
15+
- NA
16+
superseded-by:
17+
- NA
18+
---
19+
20+
# RBAC Toggle
21+
22+
## Release Signoff Checklist
23+
24+
- [ ] Enhancement is `implementable`
25+
- [ ] Design details are appropriately documented from clear requirements
26+
- [ ] Test plan is defined
27+
- [ ] Graduation criteria for dev preview, tech preview, GA
28+
29+
## Open Questions [optional]
30+
31+
NA
32+
33+
## Summary
34+
35+
The [operator-lifecycle-manager (OLM)](https://github.com/operator-framework/operator-lifecycle-manager) is responsible for installing, upgrading, and managing the lifecycle of operators. While managing the lifecycle of an operator, OLM is responsible for creating the associated [Role-Based Access Control (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) manifests.
36+
37+
Today, cluster admins cannot control the RBAC generated by OLM for the operators that it manages. This is particularly challenging OLM's efforts to promote [AllNamespace InstallMode](https://olm.operatorframework.io/docs/advanced-tasks/operator-scoping-with-operatorgroups/#targetnamespaces-and-their-relationship-to-installmodes) operators as the associated RBAC is made available in all namespaces in the cluster.
38+
39+
This enhancement proposes providing cluster admins greater control over the RBAC generated by OLM while managing an operator.
40+
41+
## Motivation
42+
43+
The primary motivation of this enhancement centers around using OLM on highly regulated clusters. Within these highly regulated environments, cluster admins are responsible for tightly limiting the permissions of users or services on the cluster. In many cases, these clusters must meet specific regulations that are regularly audited. Today, it is difficult or impossible to use OLM in these environments as the cluster admins have no control over the RBAC generated by OLM.
44+
45+
### Goals
46+
47+
- Provide means to disable promotion of Role and RoleBindings defined from the [ClusterServiceVersion.Spec.Install.Spec.Permissions field](https://github.com/operator-framework/api/blob/33310d6154f344da5494c788451bd34cdf54711c/pkg/operators/v1alpha1/clusterserviceversion_types.go#L79) to ClusterRoles and ClusterRoleBindings respectively when installing an operators into a namespace that includes an AllNamespace OperatorGroup.
48+
- Disable generation of ClusterRoles aggregated to the view, edit, and admin ClusterRoles when installing a CRD. For example, when installing a CRD named foo.bar.io at v1, OLM should not generate the following ClusterRoles:
49+
-- foo.bar.io-v1-admin
50+
-- foo.bar.io-v1-crdview
51+
-- foo.bar.io-v1-edit
52+
-- foo.bar.io-v1-view
53+
54+
> NOTE: The following Goals may not be required, but it seems reasonable that a cluster admin would not want every user to be able to view/edit CRDs introduced by OLM.
55+
- Disable generation of [aggregate-olm-edit ClusterRole](https://github.com/operator-framework/operator-lifecycle-manager/blob/943a726ab1a516bc231e2fe96d13fc2e47bf4448/deploy/upstream/quickstart/olm.yaml#L153-L167) RBAC.
56+
- Disable generation of [aggregate-olm-view ClusterRol](https://github.com/operator-framework/operator-lifecycle-manager/blob/943a726ab1a516bc231e2fe96d13fc2e47bf4448/deploy/upstream/quickstart/olm.yaml#L168-L184) RBAC.
57+
58+
### Non-Goals
59+
60+
- Provide means to disable generation of ClusterRoles and ClusterRoleBindings derived from the [ClusterServiceVersion.Spec.Install.Spec.ClusterPermissions field](https://github.com/operator-framework/api/blob/33310d6154f344da5494c788451bd34cdf54711c/pkg/operators/v1alpha1/clusterserviceversion_types.go#L80). These permissions should be limited to those that are absolutely required for the operator to run, and so OLM cannot scope these permissions down.
61+
62+
## Proposal
63+
64+
OLM recently introduced the [olmConfig resource](https://github.com/operator-framework/api/blob/33310d6154f344da5494c788451bd34cdf54711c/pkg/operators/v1/olmconfig_types.go#L40-L47) to provide users with the means to configure OLM behavior. This enhancement proposes two additional toggles to the `spec.features struct](https://github.com/operator-framework/api/blob/33310d6154f344da5494c788451bd34cdf54711c/pkg/operators/v1/olmconfig_types.go#L16-L26):
65+
```yaml
66+
// Features contains the list of configurable OLM features.
67+
type Features struct {
68+
// DisableOLMAggregateCRDRoles allows users to disable the aggregate-olm-edit and aggregate-olm-view clusterroles that ship with OLM.
69+
//
70+
// Again, the jury is still out on whether or not this field is needed.
71+
DisableOLMAggregateCRDRoles *bool `json:"disableOLMAggregateCRDRoles,omitempty"`
72+
73+
// DisableAggregateCRDRoles is used to prevent OLM from generating
74+
// clusterRoles that are aggregated to the default view, edit, and
75+
// admins roles that are shipped with Kubernetes. OLM creates these
76+
// roles so users may immediately begin interacting with APIs
77+
// introduced by operators installed with OLM.
78+
DisableAggregateCRDRoles *bool `json:"disableAggregateCRDRoles,omitempty"`
79+
80+
// DisableAllNamespacePermissionPromotion prevents OLM from escalating
81+
// roles and roleBindings requested by an operator to clusterRole and
82+
// clusterRoleBindings respectively when OLM installs an operators into
83+
// a namespace that includes an operatorGroup with the AllNamespace
84+
// installMode.
85+
DisableAllNamespacePermissionPromotion *bool `json:"disableAllNamespacePermissionPromotion,omitempty"`
86+
}
87+
```
88+
89+
Let's discuss the design of each of these toggles:
90+
91+
### DisableOLMAggregateCRDRoles Toggle
92+
93+
The goal of this toggle is to provide cluster admins with the means to prevent OLM from creating aggregated `edit` and `view` roles for the CRDs and APIServices introduced by OLM.
94+
95+
To support this toggle, the `aggregate-olm-edit` and `aggregate-olm-view` will be removed from the manifests directory and instead the [olmConfig controller](https://github.com/operator-framework/operator-lifecycle-manager/blob/3002cf79ce867e32d30d2190df642eaa7f449294/pkg/controller/operators/olm/operator.go#L1249-L1314) will be updated to inspect the `olmConfig.Spec.DisableOLMAggregateCRDRoles` field and:
96+
- Ensure that the `aggregate-olm-edit` and `aggregate-olm-view` clusterRoles exist if the `DisableOLMAggregateCRDRoles` field in is `nil` or `false`.
97+
- Ensure that the `aggregate-olm-edit` and `aggregate-olm-view` clusterRoles do not exist if the field is `true`.
98+
99+
### DisableAggregateCRDRoles Toggle
100+
101+
The goal of this toggle is to provide cluster admins with the means to prevent OLM from creating aggregated `edit`, `view`, `crdview,` and `admin` for CRDs and APIServices introduced by managed operators.
102+
103+
To support this toggle, the [ensureClusterRolesForCRD](https://github.com/operator-framework/operator-lifecycle-manager/blob/3002cf79ce867e32d30d2190df642eaa7f449294/pkg/controller/operators/olm/operatorgroup.go#L418-L457) function should be updated to inspect the `olmConfig.Spec.DisableAggregateCRDRoles` field and:
104+
- Ensure that the `edit`, `view`, `crdview,` and `admin` roleBindings exist if the field is `nil` or `false`.
105+
- Ensure that the `edit`, `view`, `crdview`, and `admin` roleBindings do not exist if the field is `true`.
106+
107+
### DisableAllNamespacePermissionPromotion Toggle
108+
109+
The goal of this toggle is to provide cluster admins with the means to prevent OLM from promotion roles and roleBindings defined in a ClusterServiceVersion (CSV) to clusterRoles and clusterRoleBindings.
110+
111+
To support this toggle, the [ensureRBACInTargetNamespace](https://github.com/operator-framework/operator-lifecycle-manager/blob/3002cf79ce867e32d30d2190df642eaa7f449294/pkg/controller/operators/olm/operatorgroup.go#L483-L484) function should be updated to inspect the `olmConfig.Spec.DisableAllNamespacePermissionPromotion` field and:
112+
- Ensure that the `permissions` are promoted to `clusterPermissions` when the field is set to `nil` or `false`.
113+
- Ensure that the `permissions` are not promoted to `clusterPermissions` when the field is set to `true`.
114+
115+
### User Stories [optional]
116+
#### Story 1
117+
118+
As a cluster admin, I would like to be able to remove the view and edit aggregate roles that OLM creates for the APIs it introduces so only a select number of users can interact with OLM.
119+
120+
#### Story 2
121+
122+
As a cluster admin, I would like to be able to configure OLM so it does not create the `edit`, `view`, `crdview,` and `admin` aggregate roleBindings for the CRDs of operators it installs.
123+
124+
#### Story 2
125+
126+
As a cluster admin, I would like to be able to configure OLM so it does not promote roles and roleBindings defined in a CSV's `spec.permissions` field to clusterRole and clusterRoleBindings respectively so I may have greater control over which namespaces the operator interacts with.
127+
128+
### Implementation Details/Notes/Constraints [optional]
129+
130+
#### Namespaced RBAC Generation
131+
132+
After installing an operator in the "AllNamespace" mode and disabling OLM's promotion of a CSV's `permissions` to `clusterPermissions` through the `DisableAllNamespacePermissionPromotion` toggle, the cluster admin will need to manually create the roles and roleBindings in each of the namespaces they want to "scope" the operator to. While this could be done manually, it may be helpful to provide support for packaging [combo](https://github.com/operator-framework/combo) or providing the steps to using the combo cli to generate the roles and roleBindings for a list of namespaces from a CSV.
133+
134+
#### Handling events from Informers
135+
136+
Operator clients are created today with informers that are configured to watch for events in specific or all namespaces at startup, there is no dynamic informer that exists today. When a cluster admin installs an operator in the "AllNamespace" mode and disables OLM's promotion of a CSV's `permissions` to `clusterPermissions` through the `DisableAllNamespacePermissionPromotion` toggle, the `Subscription's spec.config.env` field must set the `WATCH_NAMESPACE` environment variable, which is currently derived from the 'olm.targetNamespaces` annotation on the CSV. Failure to address this concern will result in the operator receiving events from namespaces in which the operator does not have the appropriate permissions to operator in.
137+
138+
### Risks and Mitigations
139+
140+
The greatest risk associated ith
141+
142+
## Design Details
143+
144+
### Test Plan
145+
146+
The following testcases should be implemented as a part of this enhancement:
147+
- Setting the `cluster olmConfig` resource's `spec.features.disableOLMAggregateCRDRoles` to `true` removes the `aggregate-olm-edit` and `aggregate-olm-view` clusterRoles from the cluster.
148+
- Setting the `cluster olmConfig` resource's `spec.features.disableAggregateCRDRoles` to `true` prevents OLM from creating `edit`, `view`, `crdview,` and `admin` roleBindings for CRDs and APIServices introduced by the CSVs.
149+
- Setting the `cluster olmConfig` resource's `spec.features.disableAllNamespacePermissionPromotion` to `true` prevents OLM from converting roles and roleBindings defined in a CSV's `spec.permissions` field to clusterRoles and clusterRoleBindings respectively.
150+
151+
### Prototype Demo [optional]
152+
153+
WIP prototype can be found [here](https://github.com/awgreene/operator-lifecycle-manager/tree/rbac-toggle-demo), this section will be updated when the prototype is in a more presentable state.
154+
155+
### Graduation Criteria
156+
157+
Straight to GA.
158+
159+
#### Examples
160+
161+
Not applicable.
162+
163+
##### Dev Preview -> Tech Preview
164+
165+
Straight to GA.
166+
167+
##### Tech Preview -> GA
168+
169+
Straight to GA.
170+
171+
##### Removing a deprecated feature
172+
173+
Not applicable.
174+
175+
### Upgrade / Downgrade Strategy
176+
177+
If OLM is downgraded the proposed changes to the API will be lost and OLM may begin generating RBAC for the operators that were created. As such, the OLM team should investigate:
178+
179+
- How OLM can prevent cluster downgrades.
180+
- How we could communicate the potential damage to customers if they initiate a downgrade after utilizing this feature.
181+
182+
### Version Skew Strategy
183+
184+
The is feature does not depend on other projects and uses existing APIs, as such there is little concern regarding the version of other components.
185+
186+
## Implementation History
187+
188+
Not applicable.
189+
190+
## Drawbacks
191+
192+
The goal of this enhancement is to provide cluster admins with greater control over the RBAC that OLM generates on cluster. Providing cluster admin's with the means to disable OLM's RBAC generation naturally places a greater burden on cluster admins to manage RBAC as they install new operators. There are a number of existing processes that become more tedious when RBAC generation is enabled, to name a few:
193+
194+
- The cluster admin must keep track of the namespaces that include the roles and roleBindings required by the operator. If the cluster admin wants to extend the scope of the operator to additional namespaces, they would need to create additional RBAC in said namespaces.
195+
- The cluster admin must keep the `WATCHED_NAMESPACES` environment variable up to date, otherwise the informer will either:
196+
-- Receive events from namespaces that it lacks the appropriate RBAC.
197+
-- Not Receive events from namespaces that it has the appropriate RBAC.
198+
## Alternatives
199+
200+
### Multi Namespace Cluster Singletons
201+
202+
A core requirements of this enhancement is to prevent OLM from promoting roles/roleBindings defined in a CSV's permissions to clusterRoles and clusterRoleBindings respectively when installing an operator in AllNamespace mode. Instead of disabling RBAC promotion by OLM, we could instead add a feature that treats MultiNamespace operatorGroups as cluster singletons, which would remove the need to modify the list of namespaces that an operator is configured to watch.
203+
204+
Unfortunately, OLM has been directing operator authors to use the AllNamespace installMode, which means that some subset of operator may not even support the MultiNamespace installMode.
205+
206+
## Infrastructure Needed [optional]
207+
208+
Not applicable.
209+

0 commit comments

Comments
 (0)