Merge pull request #34464 from mburke5678/BZ-1950408

BZ1950408: Can't SSH into RHCOS nodes - runc modified /dev/ptmx symlink (hostPath)

Author: mburke5678

modules/nodes-containers-volumes-adding.adoc

@@ -37,11 +37,11 @@ character.
 |`'*'`
 
 |`-m, --mount-path`
-|Mount path inside the selected containers.
+|Mount path inside the selected containers. Do not mount to the container root, `/`, or any path that is the same in the host and the container. This can corrupt your host system if the container is sufficiently privileged, such as the host `/dev/pts` files. It is safe to mount the host by using `/host`. 
 |
 
 |`--path`
-|Host path. Mandatory parameter for `--type=hostPath`.
+|Host path. Mandatory parameter for `--type=hostPath`. Do not mount to the container root, `/`, or any path that is the same in the host and the container. This can corrupt your host system if the container is sufficiently privileged, such as the host `/dev/pts` files. It is safe to mount the host by using `/host`.  
 |
 
 |`--secret-name`

modules/nodes-pods-using-example.adoc

@@ -55,11 +55,11 @@ spec:
       volumeMounts: <5>
         - name: default-token-wbqsl
           readOnly: true
-          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
+          mountPath: /var/run/secrets/kubernetes.io/serviceaccount <6>
       terminationMessagePolicy: File
-      image: registry.redhat.io/openshift4/ose-ogging-eventrouter:v4.3 <6>
-  serviceAccount: default <7>
-  volumes: <8> 
+      image: registry.redhat.io/openshift4/ose-ogging-eventrouter:v4.3 <7>
+  serviceAccount: default <8>
+  volumes: <9>
     - name: default-token-wbqsl
       secret:
         secretName: default-token-wbqsl
@@ -107,10 +107,11 @@ status:
 <2> The pod restart policy with possible values `Always`, `OnFailure`, and `Never`. The default value is `Always`.
 <3> {product-title} defines a security context for containers which specifies whether they are allowed to run as privileged containers, run as a user of their choice, and more. The default context is very restrictive but administrators can modify this as needed.
 <4> `containers` specifies an array of one or more container definitions.
-<5> The container specifies where external storage volumes are mounted within the container. In this case, there is a volume for storing the default the CA bundle.
-<6> Each container in the pod is instantiated from its own container image.
-<7> Pods making requests against the {product-title} API is a common enough pattern that there is a `serviceAccount` field for specifying which service account user the pod should authenticate as when making the requests. This enables fine-grained access control for custom infrastructure components.
-<8> The pod defines storage volumes that are available to its container(s) to use. In this case, it provides an ephemeral volume for a `secret` volume containing the default service account tokens.
+<5> The container specifies where external storage volumes are mounted within the container. In this case, there is a volume for storing access to credentials the registry needs for making requests against the {product-title} API.
+<6> Specify the volumes to provide for the pod. Volumes mount at the specified path. Do not mount to the container root, `/`, or any path that is the same in the host and the container. This can corrupt your host system if the container is sufficiently privileged, such as the host `/dev/pts` files. It is safe to mount the host by using `/host`.
+<7> Each container in the pod is instantiated from its own container image.
+<8> Pods making requests against the {product-title} API is a common enough pattern that there is a `serviceAccount` field for specifying which service account user the pod should authenticate as when making the requests. This enables fine-grained access control for custom infrastructure components.
+<9> The pod defines storage volumes that are available to its container(s) to use. In this case, it provides an ephemeral volume for a `secret` volume containing the default service account tokens.
 
 [NOTE]
 ====

modules/persistent-storage-hostpath-about.adoc

@@ -10,3 +10,29 @@
 In a production cluster, you would not use hostPath. Instead, a cluster administrator would provision a network resource, such as a GCE Persistent Disk volume, an NFS share, or an Amazon EBS volume. Network resources support the use of storage classes to set up dynamic provisioning.
 
 A hostPath volume must be provisioned statically.
+
+[IMPORTANT]
+====
+Do not mount to the container root, `/`, or any path that is the same in the host and the container. This can corrupt your host system if the container is sufficiently privileged. It is safe to mount the host by using `/host`. The following example shows the `/` directory from the host being mounted into the container at `/host`.
+
+[source,yaml]
+----
+apiVersion: v1
+kind: Pod
+metadata:
+  name: test-host-mount
+spec:
+  containers:
+  - image: registry.access.redhat.com/ubi8/ubi
+    name: test-container
+    command: ['sh', '-c', 'sleep 3600']
+    volumeMounts:
+    - mountPath: /host
+      name: host-slash
+  volumes:
+   - name: host-slash
+     hostPath:
+       path: /
+       type: ''
+----
+====

modules/persistent-storage-hostpath-pod.adoc

@@ -37,5 +37,5 @@ spec:
 ----
 <1> The name of the pod.
 <2> The pod must run as privileged to access the node's storage.
-<3> The path to mount the hostPath share inside the privileged pod.
+<3> The path to mount the host path share inside the privileged pod. Do not mount to the container root, `/`, or any path that is the same in the host and the container. This can corrupt your host system if the container is sufficiently privileged, such as the host `/dev/pts` files. It is safe to mount the host by using `/host`.
 <4> The name of the `PersistentVolumeClaim` object that has been previously created.

modules/persistent-storage-hostpath-static-provisioning.adoc

@@ -32,7 +32,7 @@ A pod that uses a hostPath volume must be referenced by manual (static) provisio
 <1> The name of the volume. This name is how it is identified by persistent volume claims or pods.
 <2> Used to bind persistent volume claim requests to this persistent volume.
 <3> The volume can be mounted as `read-write` by a single node.
-<4> The configuration file specifies that the volume is at `/mnt/data` on the cluster's node.
+<4> The configuration file specifies that the volume is at `/mnt/data` on the cluster's node. Do not mount to the container root, `/`, or any path that is the same in the host and the container. This can corrupt your host system. It is safe to mount the host by using `/host`. 
 
 . Create the PV from the file:
 +

modules/persistent-storage-local-pod.adoc

@@ -33,7 +33,7 @@ spec:
       claimName: local-pvc-name <3>
 ----
 <1> The name of the volume to mount.
-<2> The path inside the pod where the volume is mounted.
+<2> The path inside the pod where the volume is mounted. Do not mount to the container root, `/`, or any path that is the same in the host and the container. This can corrupt your host system if the container is sufficiently privileged, such as the host `/dev/pts` files. It is safe to mount the host by using `/host`.
 <3> The name of the existing persistent volume claim to use.
 
 . Create the resource in the {product-title} cluster, specifying the file

modules/storage-persistent-storage-azure-file-pod.adoc

@@ -33,5 +33,5 @@ spec:
         claimName: claim1 <3>
 ----
 <1> The name of the pod.
-<2> The path to mount the Azure File share inside the pod.
+<2> The path to mount the Azure File share inside the pod. Do not mount to the container root, `/`, or any path that is the same in the host and the container. This can corrupt your host system if the container is sufficiently privileged, such as the host `/dev/pts` files. It is safe to mount the host by using `/host`.
 <3> The name of the `PersistentVolumeClaim` object that has been previously created.

modules/storage-persistent-storage-pvc.adoc

@@ -101,6 +101,6 @@ spec:
       persistentVolumeClaim:
         claimName: myclaim <3>
 ----
-<1> Path to mount the volume inside the pod
-<2> Name of the volume to mount
-<3> Name of the PVC, that exists in the same namespace, to use
+<1> Path to mount the volume inside the pod.
+<2> Name of the volume to mount. Do not mount to the container root, `/`, or any path that is the same in the host and the container. This can corrupt your host system if the container is sufficiently privileged, such as the host `/dev/pts` files. It is safe to mount the host by using `/host`.
+<3> Name of the PVC, that exists in the same namespace, to use.