According http://static.open-scap.org/ssg-guides/ssg-ocp4-guide-cis.html#xccdf_org.ssgproject.content_rule_rbac_wildcard_use the usage of wildcard in ClusterRole and Roles should be prevented as best as possible. Further, one should refrain from using `cluster-admin` permissions to comply with CIS security requirements. It's therefore requested to review the below serviceAccount and their associated Roles as they were found not to be compliant with the above and restrict permissions further to the extend possible. - system:serviceaccount:openshift-dns-operator:dns-operator
Setting blocker-. (In reply to Simon Reber from comment #0) > According > http://static.open-scap.org/ssg-guides/ssg-ocp4-guide-cis.html#xccdf_org. > ssgproject.content_rule_rbac_wildcard_use the usage of wildcard in > ClusterRole and Roles should be prevented as best as possible. We might be able to tie down some permissions, such as restricting the operator's access to clusteroperators to allow access only to the "dns" clusteroperator or restricting the operator to managing daemonsets etc. in only the operand namespace. However, the operand (and therefore the operator) by its nature requires some wildcard permissions. For example, CoreDNS needs access to all services and endpointslices in all namespaces in the cluster so that it can respond to DNS queries for those services' names with the addresses in the endpointslices. > Further, one should refrain from using `cluster-admin` permissions to comply > with CIS security requirements. Can you elaborate on this point? > It's therefore requested to review the below serviceAccount and their > associated Roles as they were found not to be compliant with the above and > restrict permissions further to the extend possible. > > - system:serviceaccount:openshift-dns-operator:dns-operator Is this part of a larger audit of cluster operators? It would be useful to define applicable guidelines for all cluster operators to follow.
This issue is stale and has been closed because it has been open 90 days or more with no noted activity/comments in the last 60 days. If this issue is crucial and still needs resolution, please open a new jira issue and the engineering team will triage and prioritize accordingly.