Remove hard-coded and extensive ClusterRoles for compliance-operator and api-resource-collector

[JAORMX]

Context

These were originally added as they seemed to be a mechanism to grant permissions to the multiple resources the Compliance Operator needs to access. With every new resource type that's supported in the content, we have to update deploy/roles.yaml, and keep these in sync.

This enforces a dependency on the content version and the operator version. As older operator versions are not able to support newer content with new resources.

Proposal

Let's remove these extensive roles and instead use impersonation to do the task we need [1] [2].

With this, the compliance-operator would need to impersonate cluster-admin for remediations, while the api-resource-collector would impersonate cluster-reader for accessing resources.

This has the added benefit that we would be able to remove remediation privileges in an easier manner, by simply removing the ability to impersonate from the compliance-operator service account.

References

[1] https://techbloc.net/archives/4421
[2] https://johnharris.io/2019/08/least-privilege-in-kubernetes-using-impersonation/

[mrogers950]

I can see how this could make content permissions simpler to deal with, but I'm hesitant to agree doing it for an operator service accounts. Mainly is that when you have to hard-code the operator client to do --as, it's no different than just binding the compliance-operator service account to cluster-admin. Even if we enabled it for only one client call, it would give that call more permissions than it gets today. IIRC also with impersonation, there's an API log for the impersonation action, but subsequent actions appear only as the impersonated user, making it harder to audit.

In general, it seems like a pretty big widening of permissions for something that we might be able to manage better outside of the operator.

This enforces a dependency on the content version and the operator version. As older operator versions are not able to support newer content with new resources.

I thought about this some more - I don't think we've made a specific effort to support new content images on old operator versions before.. Not just due to resource permissions but because of other changes.

[JAORMX]

@mrogers950 the impersonated user and the actua user appear in the audit trail [1]. Auditing should not be a problem in regards to using impersonation.

[1] https://docs.bitnami.com/tutorials/simplify-kubernetes-resource-access-rbac-impersonation/#audit-trails