Where does the controller require read access to Secrets?

[WillSewell]

By default, the ClusterRole gives read access to all Secrets in the cluster.

argo-rollouts/manifests/role/argo-rollouts-clusterrole.yaml

Lines 92 to 101 in 7b69058

	# secret read access to run analysis templates which reference secrets
	- apiGroups:
	- ""
	resources:
	- secrets
	- configmaps
	verbs:
	- get
	- list
	- watch

We would like to forbid the controller from access secrets it doesn't need to.

In this discussion, @jessesuen points at that the read access to Secrets is required by AnalysisRuns. We do not require references to Secrets in our AnalysisRuns, so I was hoping we could just remove the reference to the secret resource from the ClusterRole. However we are still observing the same error:

E0222 10:48:36.401540       1 reflector.go:138] pkg/mod/k8s.io/client-go@v0.20.4/tools/cache/reflector.go:167: Failed to watch *v1.Secret: failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:io-gmon:argo-rollouts" cannot list resource "secrets" in API group "" in the namespace "io-gmon"

Are there other places in the controller where secrets are requested? For example we are using notifications, and it looks like notifications-engine depends on a SecretInformer, which I think might be causing this error. Are there other places where Secrets might be referenced? It's tricky to investigate because the error message is being logged from within the client-go, and there is no stack trace linking it back to the call site in the rollouts controller.

We don't actually require the use of argo-rollouts-notification-secret Secret. Given this, are there any workarounds to getting the argo rollouts controller running without giving it access to all Secrets?