Does patch operator really require cluster-wide permissions?

[larsks]

I've configured a ServiceAccount (patch-operator) with permissions to read and modify secrets and configmaps in a particular namespace. I have this role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: patch-operator
rules:
- apiGroups:
  - ""
  resources:
  - secrets
  - configmaps
  verbs:
  - create
  - update
  - patch
  - get
  - list
  - watch
  - delete

And this rolebinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: patch-operator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: patch-operator
subjects:
- kind: ServiceAccount
  name: patch-operator

But when I deploy a patch that attempts to read from a ConfigMap and write to a Secret:

apiVersion: redhatcop.redhat.io/v1alpha1
kind: Patch
metadata:
  name: dex-config
spec:
  patches:
    dex-config:
      patchTemplate: |
        data:
          dex.config: "{{ (index . 1).data.config }}"
      sourceObjectRefs:
      - apiVersion: v1
        kind: Secret
        name: dex-config
        namespace: '{{ .metadata.namespace }}'
      targetObjectRef:
        apiVersion: v1
        kind: ConfigMap
        name: argocd-cm
        namespace: '{{ .metadata.namespace }}'
  serviceAccountRef:
    name: patch-operator

I see the manager logging:

E0919 20:29:05.707142 1 reflector.go:138] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: Failed to watch /v1, Kind=Secret: failed to list /v1, Kind=Secret: secrets is forbidden: User "system:serviceaccount:lars-sandbox:patch-operator" cannot list resource "secrets" in API group "" at the cluster scope

The SA demonstrably has appropriate permissions in the namespace, for example, I can do this:

TOKEN="$(oc sa get-token patch-operator)"
kubectl --token="$TOKEN" patch cm argocd-cm -p '{"data": {"dex-config": "this is a test"}}'
configmap/argocd-cm patched

Why is the patch operator trying to list resources in the cluster scope, rather than using the namespace scope? I don't want the service account to have cluster-wide Secrets access.

[leotomas837]

@larsks

I am facing the same issue. It may be because sourceObjectRefs[].namespace is not taken into account, so your patch would be applied to all secrets with name dex-config (max one per namespace). Did you figure it out or you simply gave cluster-wide permissions ?

[larsks]

We just assigned cluster-wide permissions (and then realized that we didn't need the patch operator for what we were trying to do after all).

[leotomas837]

Thanks for coming back to me that quickly !

Yes I just saw thread #4 where you chased the issue and I saw your commit. Never mind, the permissions are cluster-wide but the target is namespaced (it works as expected), so it should be ok.