Securing VAST CSI Driver in Multi-Tenant Environment

Do not run your container as privileged.

This will block root from within a container from mounting, as shown in the following example where root within a container has searched the mount point, created a directory and attempted to mount, but failed:

[root@es-master-0 elasticsearch]# mkdir /mnttest
[root@es-master-0 elasticsearch]# mount|grep elastic
10.101.12.16:/elastic/pvc-44b42a13-8dc1-47ff-8c9c-2092311bde1f on /usr/share/elasticsearch/data type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=rdma,port=20049,timeo=600,retrans=2,sec=sys,mountaddr=10.101.12.16,mountvers=3,mountproto=tcp,local_lock=none,addr=10.101.12.16)           
[root@es-master-0 elasticsearch]# mount -t nfs 10.101.12.16:/elastic /mnttestmount: permission denied

Isolate your pods and establish a proper flow of NFS calls from the container to the NFS server.

By default, pods are not isolated; they accept traffic from any source and can send traffic to any destination.

Pods become isolated by having a network policy that selects them. Once there is a network policy in a namespace selecting a particular pod, Kubernetes will reject any inbound or outbound connections that are not allowed by any network policy. Other pods in the namespace that are not selected by any network policy will continue to accept all traffic.

POSIX system calls from within a container are traveling out of the container to the NFS client on the host, and it is from the host that NFS packets are sent to the NFS server. So with proper network isolation, the container cannot communicated directly with the NFS server, even though it knows its IP from the mount information.