Use HostToContainer mount propagation instead of Bidirectional

Kubernetes only allows using `Bidirectional` mount propagation on
privileged containers. But making a container privileged causes
containerd to reset container's SELinux labels, and that causes
problems with Bottlerocket.

Because we spawn Mountpoint processes on the host by using systemd,
Bottlerocket's SELinux policies by default denies that. In order to
overcome this limitation we're using `super_t` SELinux label in our
containers which then they become "superpowered" containers and
bypasses the limitation.

So, if we make our containers privileged, due to containerd's
behaviour we lose our `super_t` SELinux label and Bottlerocket blocks
our container to spawn systemd processes.

Signed-off-by: Burak Varlı <burakvar@amazon.co.uk>

charts/aws-mountpoint-s3-csi-driver/templates/node.yaml

@@ -72,11 +72,8 @@ spec:
         - name: s3-plugin
           image: {{ printf "%s%s:%s" (default "" .Values.image.containerRegistry) .Values.image.repository (default (printf "v%s" .Chart.AppVersion) (toString .Values.image.tag)) }}
           securityContext:
-            # This is needed because we do `Bidirectional` mount on `/var/lib/kubelet` to propagate mounts
-            # from host to our Pod. This relation will reverse once we implement https://github.com/awslabs/mountpoint-s3-csi-driver/issues/279,
-            # then we will do the mount on the Pod and will propagate that mount to host for other Pods to consume.
-            privileged: true
             readOnlyRootFilesystem: true
+            allowPrivilegeEscalation: false
             {{- with .Values.node.seLinuxOptions }}
             seLinuxOptions:
               user: {{ .user }}
@@ -125,7 +122,11 @@ spec:
           volumeMounts:
             - name: kubelet-dir
               mountPath: {{ .Values.node.kubeletPath }}
-              mountPropagation: Bidirectional
+              # Currently we spawn Mountpoint instances on the host using systemd,
+              # "HostToContainer" allows any newly created mounts inside kubelet path to propagated to the container.
+              # Thanks to this, we can do "is mount point?" checks for volumes provided by the CSI Driver
+              # without needing to mount "/proc/mounts" from host.
+              mountPropagation: HostToContainer
             - name: plugin-dir
               mountPath: /csi
             - name: systemd-bus

deploy/kubernetes/base/node-daemonset.yaml

@@ -60,11 +60,9 @@ spec:
         - name: s3-plugin
           image: csi-driver
           securityContext:
-            # This is needed because we do `Bidirectional` mount on `/var/lib/kubelet` to propagate mounts
-            # from host to our Pod. This relation will reverse once we implement https://github.com/awslabs/mountpoint-s3-csi-driver/issues/279,
-            # then we will do the mount on the Pod and will propagate that mount to host for other Pods to consume.
-            privileged: true
             readOnlyRootFilesystem: true
+            allowPrivilegeEscalation: false
+            privileged: false
             seLinuxOptions:
               user: system_u
               type: super_t
@@ -109,7 +107,11 @@ spec:
           volumeMounts:
             - name: kubelet-dir
               mountPath: /var/lib/kubelet
-              mountPropagation: Bidirectional
+              # Currently we spawn Mountpoint instances on the host using systemd,
+              # "HostToContainer" allows any newly created mounts inside kubelet path to propagated to the container.
+              # Thanks to this, we can do "is mount point?" checks for volumes provided by the CSI Driver
+              # without needing to mount "/proc/mounts" from host.
+              mountPropagation: HostToContainer
             - name: plugin-dir
               mountPath: /csi
             - name: systemd-bus