The comparison of SELinux labels in KCM tolerates missing fields - the
operating system is going to default them from its defaults, but in KCM we
don't know what the defaults are.
But the OS won't default the last component, "level", which includes also
categories. Make sure that labels with a level set conflicts with level "",
that's what will conflict on the OS too.
Pod that explicitly opted into "seLinuxChangePolicy: Recursive" should not
report conflicts with another SELinux labels. They will only report a
conflict with other Pods using the same volume with "seLinuxChangePolicy:
Mount" (or nil).
A real SELinuxOptionsToFileLabel function needs access to host's
/etc/selinux to read the defaults. This is not possible in
kube-controller-manager that often runs in a container and does not have
access to /etc on the host. Even if it had, it could run on a different
Linux distro than worker nodes.
Therefore implement a custom SELinuxOptionsToFileLabel that does not
default fields in SELinuxOptions and uses just fields provided by the Pod.
Since the controller cannot default empty SELinux label components,
treat them as incomparable.
Example: "system_u:system_r:container_t:s0:c1,c2" *does not* conflict with ":::s0:c1,c2",
because the node that will run such a Pod may expand "":::s0:c1,c2" to "system_u:system_r:container_t:s0:c1,c2".
However, "system_u:system_r:container_t:s0:c1,c2" *does* conflict with ":::s0:c98,c99".
selinux_volume_conflict should not have space in its label value - it's
harder to query for that value. Use SELinuxLabel as both human friendly (in
an event) and label value.
* Remove Controller.recorder field, there already is eventRecorder.
* Start the event broadcaster in Run(), to save a bit of CPU and memory
when something initializes the controller, but does not Run() it.
* Log events with log level 3, as the other contollers usually do.
* Use StartStructuredLogging(), which looks fancier than StartLogging
