Do not allow gatekeeper to self-manage

[maxsmythe]

Signed-off-by: Max Smythe smythe@google.com

[ritazh]

Hi @maxsmythe With this PR, I was expecting the following test to succeed. Can you please verify if this is the expected behavior? Perhaps I missed something in the deployment.

Repro steps:

1. Deploy all gatekeeper things
2. Deploy k8suniquelabels_template.yaml, then deploy a constraint that checks for label gatekeeper on pod

apiVersion: constraints.gatekeeper.sh/v1alpha1
kind: K8sRequiredLabels
metadata:
  name: pod-must-have-gk
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    labels: ["gatekeeper"]

3. Run kubectl -n gatekeeper-system edit statefulset gatekeeper-controller-manager to update replicas from 1 to 2.
4. Result:
   Expected behavior:
   With no self-manage, there should be another gatekeeper pod created and running.
   Actual behavior:
   kubectl -n gatekeeper-system describe statefulset.apps/gatekeeper-controller-manager resulted in:

  Warning  FailedCreate      18s (x23 over 4m)  statefulset-controller  create Pod gatekeeper-controller-manager-1 in StatefulSet gatekeeper-controller-manager failed error: admission webhook "validation.gatekeeper.sh" denied the request: you must provide labels: {"gatekeeper"}

Without the constraint, there is no issue with updating the replicas to 2.

[maxsmythe]

Seems to me WAI. The stateful set controller isn't running in the gatekeeper-system namespace, which means its service account isn't part of the excluded set of service accounts.

I think it's open to debate whether any objects in the gatekeeper-system namespace should be subject to constraints at all, but this change at least removes the friction around sync finalizers and out-of-compliance resources.