You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For Pods that want to opt-out from relabeling using mount options, they can set
715
+
`spec.securityContext.seLinuxChangePolicy`to `Recursive`. This is required
716
+
when multiple pods share a single volume on the same node, but they run with
717
+
different SELinux labels that allows simultaneous access to the volume. For example, a privileged pod
718
+
running with label `spc_t` and an unprivileged pod running with the default label `container_file_t`.
719
+
With unset `spec.securityContext.seLinuxChangePolicy` (or with the value `MountOption`),
720
+
only one of such pods is able to run on a node, the other one gets ContainerCreating with error
721
+
`conflicting SELinux labels of volume <name of the volume>: <label of the running pod> and <label of the pod that can't start>`.
722
+
723
+
#### SELinuxWarningController
724
+
To make it easier to identify Pods that are affected by the change in SELinux volume relabeling,
725
+
a new controller called `SELinuxWarningController` has been introduced in kube-controller-manager.
726
+
It is disabled by default and can be enabled by setting the `--controllers=*,selinux-warning-controller` command line flag
727
+
and `SELinuxChangePolicy` feature gate.
728
+
When enabled, the controller observes running Pods and when it detects that two Pods use the same volume
729
+
with different SELinux labels:
730
+
1. It emits an event to both of the Pods. `kubectl describe pod <pod-name>` the shows
731
+
`SELinuxLabel "<label on the pod>" conflicts with pod <the other pod name> that uses the same volume as this pod
732
+
with SELinuxLabel <the other pod label>. If both pods land on the same node, only one of them may access the volume`.
733
+
2. Raise `selinux_warning_controller_selinux_volume_conflict` metric. The metric has both pod
734
+
names + namespaces as labels to identify the affected pods easily.
735
+
736
+
A cluster admin can use this information to identify pods affected by the planning change and pro-actively opt-out Pods from the optimization (i.e. set `spec.securityContext.seLinuxChangePolicy: Recursive`).
737
+
738
+
#### Feature gates
739
+
740
+
The following feature gates control the behavior of SELinux volume relabeling:
741
+
742
+
* `SELinuxMountReadWriteOncePod`: enables the optimization for volumes with `accessModes: ["ReadWriteOncePod"]`.
743
+
This is a very safe feature gate to enable, as it cannot happen that two pods can share one single volume with
744
+
this access mode. This feature gate is enabled by default sine v1.28.
745
+
* `SELinuxChangePolicy`: enables `spec.securityContext.seLinuxChangePolicy` field in Pod and related SELinuxWarningController
746
+
in kube-controller-manager. This feature can be used before enabling `SELinuxMount` to check Pods running on a cluster,
747
+
and to pro-actively opt-out Pods from the optimization.
748
+
This feature gate requires `SELinuxMountReadWriteOncePod` enabled. It is alpha and disabled by default in 1.32.
749
+
* `SELinuxMount` enables the optimization for all eligible volumes. Since it can break existing workloads, we recommend
750
+
enabling `SELinuxChangePolicy` feature gate + SELinuxWarningController first to check the impact of the change.
751
+
This feature gate requires `SELinuxMountReadWriteOncePod` and `SELinuxChangePolicy` enabled. It is alpha and disabled
752
+
by default in 1.32.
710
753
711
754
## Managing access to the `/proc` filesystem {#proc-access}
0 commit comments