OperatorGroup aggregate roles include wildcards which violate Kubernetes CIS 5.1.3

[cdjohnson]

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.

[cdjohnson]

Related Enhancement PR:
operator-framework/enhancements#116

[dmesser]

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?

[github-actions]

Issues go stale after 90 days of inactivity. If there is no further activity, the issue will be closed in another 30 days.

[github-actions]

This issue has been closed due to inactivity.