operator-lifecycle-manager
operator-lifecycle-manager copied to clipboard
operator-framework
OperatorGroup aggregate roles include wildcards which violate Kubernetes CIS 5.1.3
Feature Request
Is your feature request related to a problem? Please describe. The OpenShift Compliance Operator includes a CIS Benchmark rule set that enforces the OpenSCAP CIS OpenShift 4 Benchmark which includes Kubernetes CIS Benchmark 5.1.3:
- http://static.open-scap.org/ssg-guides/ssg-ocp4-guide-cis.html#xccdf_org.ssgproject.content_rule_rbac_wildcard_use
- https://workbench.cisecurity.org/sections/749036/recommendations/1223538
Defining OperatorGroups intentionally creates ClusterRoles with wildcards which violates one of the rules:
- https://olm.operatorframework.io/docs/concepts/crds/operatorgroup/#rbac
Describe the solution you'd like Instead of providing wildcards for the verbs for the CRDs and APIs provided by the operator, provide instructions in the ClusterServiceVersion that describe what verbs the controller needs.
Related Enhancement PR: https://github.com/operator-framework/enhancements/pull/116
The linked enhancement is only tangentially related, it's aim is to disable the aggregation altogether to make room for custom RBAC to be put in place. What the benchmark is complaining about is the * access with give namespace admins on the APIs that the operator creates in question provides. Arguably this is very useful as we don't know what an admin / user might want to do with those APIs. If we want to satisfy the report, is it an option to just spell out the specific verbs we want namespace admins to have on operator APIs?
