Ansible operators usage of WATCH_NAMESPACE env variable may lead to unnecessary privilege escalations

Bug Report

What did you do?

This is a follow-on and related to #2461.

I deployed an Ansible Operator with no WATCH_NAMESPACE environment variable defined. This operator needs RBACs to work with some resources in the current namespace as well as resources in other namespaces.

Hypothetically, to focus on the potential security exposure or unnecessary privilege escalation here... let's say I'm creating a secret-sprayer Ansible Operator. It's purpose is to read Secrets from the current namespace and create a Custom Resource Foo in another namespace with some of the data from that Secret.

The design discussed in #2461, and also in the official operator-sdk doc around golang manager client scopes, here, seem to indicate that when the WATCH_NAMESPACE env variable is omitted, the manager client that is created will be expecting cluster-scoped authority.

It also seems that the guidance is then to move all permissions needed by your operator in the CSV into clusterPermissions in order to now work with the cluster-scoped manager.

However, in this case, the service account that is now created is given permissions to get Secrets from ALL namespaces, even though, I only need it to read Secrets from the namespace in which my secret-sprayer Operator is running. I only need the clusterPermissions to create my Foo CRs in the other namespaces!

What did you expect to see?

Ansible Operators that could correctly run with clients that interact at both the namespace scope and cluster scope as necessary.

What did you see instead? Under which circumstances?

Golang manager/client errors indicating failures to work with Secrets at the cluster scope. Even though the operator's CSV had proper namespace-scoped permissions defined for the Secret.

Environment

Operator type:
language ansible

Kubernetes cluster type:
OpenShift 4.10

$ operator-sdk version
v1.8

Possible Solution

Create multiple manager clients, one namespace-scoped for the RBAC rules defined in the CSV's permissions block, and another for RBAC rules that are defined in the CSV's clusterPermissions block.

Additional context

I used Secrets in the hypothetical example because you could see how this could be an unnecessary privilege escalation. My operator only needs to read Secrets from the current namespace, but, I'm forced to grant it permissions to read Secrets from all namespaces.

In terms of threat modeling and ensuring privilege escalations are blocked as much as possible, this is an unintended side-effect for the way I'd like my workload to run.