7

I would like to access a Windows file share share (SMB3) from a docker container, but I do not want to compromise the security of the host machine. All the guides I have read state that I need to use either the --privileged flag or --cap-add SYS_ADMIN capability.

Here is the command I use:

mount -t cifs -o username='some_account@mydomain.internal',password='some_password' //192.168.123.123/MyShare /mnt/myshare

Which results in the message:

Unable to apply new capability set.

When I apply the --cap-add SYS_ADMIN capability the mount command works fine, but I understand this exposes the host to obvious security vulnerabilities.

I have also read the suggestion in this StackOverflow question (Mount SMB/CIFS share within a Docker container) to mount the volume locally on the server that runs docker. This is undesirable for two reasons, firstly, the container is orchestrated by a Rancher Kubernetes cluster and I don't know how to achieve what is described by nPcomp using Rancher, and two, this means the volume is accessible to the docker host. I'd prefer only the container have access to this share via the credentials given to it via secrets.

My question is: is there way to mount a CIFS/SMB3 share in a docker container (within Kubernetes) without exposing the host to privilege escalation vulnerabilities and protecting the credentials? Many thanks.

ben
  • 321
  • 4
  • 12
  • Do not try to mount(8) from within a container; you should usually expect the container's network and filesystem environment to be set up when the container starts. For a Kubernetes setup you might look at [Accessing CIFS files from pods](https://stackoverflow.com/questions/67632578/accessing-cifs-files-from-pods) and similar questions which discuss installing a CIFS Kubernetes volume driver, which you can then mount like any other volume. – David Maze Sep 30 '21 at 14:41
  • Hi David - thanks for that. That approach deploys a shell script, which in turn calls mount. This requires me to install cifs-utils manually to each of the worker nodes, and also mounts the volume on the host where I was hoping to avoid. But this seems to be the way it is done in Kubernetes, so thank you for the guide. I'm going to try to use the solution created by https://github.com/fstab/cifs. – ben Sep 30 '21 at 23:46

1 Answers1

9

After more research I have figured out how to do this. There is a Container Storage Interface (CSI) driver for SMB called SMB CSI Driver for Kubernetes (https://github.com/kubernetes-csi/csi-driver-smb).

After installing the CSI driver using helm (https://github.com/kubernetes-csi/csi-driver-smb/tree/master/charts) you can follow the example at https://github.com/kubernetes-csi/csi-driver-smb/blob/master/deploy/example/e2e_usage.md (Option #2 Create PV/PVC) to create a Persistent Volume (PV) and Persistent Volume Claim (PVC) which mounts the SMB3 share.

Then you create your container and give it the relevant Persistent Volume Claim, specifying you want to mount it as /mnt/myshare etc.

I tested this and it gets deployed to multiple worker nodes automatically and works well, without needing the privileged flag or --cap-add SYS_ADMIN to be given to the containers.

This supports SMB3 and even authentication & encryption. To enable encryption go to your Windows Server > File and Storage Services, select the share, Properties > Settings > Encrypt Data Access.

Wireshark shows all the SMB traffic is encrypted. Only thing I don't recall is if you have to install cifs-utils manually first, since I had already done this on all my nodes I wasn't able to test.

Hope this helps somebody.

ben
  • 321
  • 4
  • 12