Failed to list/watch errors in ansible operator logs when without cluster scope RBAC

Hello!

We have created an ansible operator using operator-sdk v1.41.1 which needs to read credentials from a Secret to do it's job. Following the principle of least privilege, we gave it permission to access only Secrets named in certain way:

  ## 
  ## Restricted Secret access - ONLY secrets named 'certain-name-secret'
  ## 
  - apiGroups:
      - ""
    resources:
      - secrets
    verbs:
      - get 
      - list
      - watch
    resourceNames:
      - certain-name-secret

The operator works correctly, but it does frequently complain about lack of list/watch access to all Secrets in the cluster. Example log for missing watch permission:

{"level":"error","ts":"2025-11-14T03:35:11Z","logger":"controller-runtime.cache.UnhandledError","msg":"Failed to watch","reflector":"pkg/mod/k8s.io/client-go@v0.33.4/tools/cache/reflector.go:285","type":"/v1, Kind=Secret","error":"failed to list /v1, Kind=Secret: secrets is forbidden: User \"system:serviceaccount:rh-infoblox-operator-system:rh-infoblox-operator-controller-manager\" cannot list resource \"secrets\" in API group \"\" at the cluster scope","stacktrace":"k8s.io/apimachinery/pkg/util/runtime.logError\n\t/home/runner/go/pkg/mod/k8s.io/apimachinery@v0.33.4/pkg/util/runtime/runtime.go:226\nk8s.io/apimachinery/pkg/util/runtime.handleError\n\t/home/runner/go/pkg/mod/k8s.io/apimachinery@v0.33.4/pkg/util/runtime/runtime.go:217\nk8s.io/apimachinery/pkg/util/runtime.HandleErrorWithContext\n\t/home/runner/go/pkg/mod/k8s.io/apimachinery@v0.33.4/pkg/util/runtime/runtime.go:203\nk8s.io/client-go/tools/cache.DefaultWatchErrorHandler\n\t/home/runner/go/pkg/mod/k8s.io/client-go@v0.33.4/tools/cache/reflector.go:200\nk8s.io/client-go/tools/cache.(*Reflector).RunWithContext.func1\n\t/home/runner/go/pkg/mod/k8s.io/client-go@v0.33.4/tools/cache/reflector.go:360\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1\n\t/home/runner/go/pkg/mod/k8s.io/apimachinery@v0.33.4/pkg/util/wait/backoff.go:233\nk8s.io/apimachinery/pkg/util/wait.BackoffUntilWithContext.func1\n\t/home/runner/go/pkg/mod/k8s.io/apimachinery@v0.33.4/pkg/util/wait/backoff.go:255\nk8s.io/apimachinery/pkg/util/wait.BackoffUntilWithContext\n\t/home/runner/go/pkg/mod/k8s.io/apimachinery@v0.33.4/pkg/util/wait/backoff.go:256\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil\n\t/home/runner/go/pkg/mod/k8s.io/apimachinery@v0.33.4/pkg/util/wait/backoff.go:233\nk8s.io/client-go/tools/cache.(*Reflector).RunWithContext\n\t/home/runner/go/pkg/mod/k8s.io/client-go@v0.33.4/tools/cache/reflector.go:358\nk8s.io/client-go/tools/cache.(*controller).RunWithContext.(*Group).StartWithContext.func3\n\t/home/runner/go/pkg/mod/k8s.io/apimachinery@v0.33.4/pkg/util/wait/wait.go:63\nk8s.io/apimachinery/pkg/util/wait.(*Group).Start.func1\n\t/home/runner/go/pkg/mod/k8s.io/apimachinery@v0.33.4/pkg/util/wait/wait.go:72"}

It seems to have to do with caching. Can we avoid having those frequent failures while keeping RBAC scoped down? Can we disable caching for Secrets altogether maybe?

Thank you for your assistance.

No repository files or tests are identified in the issue. Start by tracing the controller-runtime cache and Secret list/watch setup responsible for the reported reflector errors, using the operator-sdk v1.41.1 behavior as context. Done means the operator retains access to the named Secret without repeatedly logging cluster-scope list/watch failures under restricted RBAC.