[1] Add "control-plane: true" labels to relevant namespaces

[cristiklein]

Currently, we have two issues:

1. Gatekeeper/OPA tends to validate things it should not validate, e.g., kube-system and gatekeeper-system.
2. Ops cannot distinguish between control-plane alerts (e.g., OPA and Falco) and data-plane alerts (e.g., WordPress, user application hosted in Compliant Kubernetes).

To fix these two issues, we decided to properly set the control-plane: true label on all relevant namespaces.

Acceptance criteria:

1. When creating a new CK8s cluster, "system" namespaces (e.g., kube-system, gatekeeper-system) should have the control-plane: true label.
2. When re-applying CK8s, "system" namespaces (e.g., kube-system, gatekeeper-system) should have the control-plane: true label.

[Xartos]

What is considered a "control-plane" namespace? If it's all "elastisys" namespaces then we already have the owner: operator label that is on all "our" namespaces.
So it feels a bit unnecessary to add yet another label just for this.

[cristiklein]

What is considered a "control-plane" namespace? If it's all "elastisys" namespaces then we already have the owner: operator label that is on all "our" namespaces.
So it feels a bit unnecessary to add yet another label just for this.

This issue was specifically referring to the ability of preventing webhooks from blocking the starting up of Pods in kube-system. The control-plane label is pretty established. I feel it is a bit orthogonal to owner. E.g., Elastisys may "own" the harbor namespace, but Gatekeeper/Cert-manager may still enable hooks in that namespace.

[Xartos]

Hmm, I have never seen that label. And according to this, it's old remains and might be depricated open-policy-agent/gatekeeper#1061

[OlleLarsson]

Pro tip: don't use "`" in issue names, it made me unable to link to this issue in a pr.
Also, please unlink this issue from the pr if it does not solve this issue.

[cristiklein]

Also, don't call your kids "drop table": https://xkcd.com/327/ 😂