Skip to main content

Secure nested LCOW: Part 3

Part 3: Getting all together

After the configuration of the Docker daemon on the Nested Hyper-V VM (part 2), it's now finally time to configure the Docker client that will connect to it.

Once again, I will be using WSL as the main shell. However, if you choose to go with Powershell, it's OK too (simply I won't explain it here :).

Setup: Window 10 Docker Client

first of all, the docker client needs to be installed in the WSL environment.
And this will be as easy as one command line, thanks to the Docker install script:
client:~$ curl -sSL https://get.docker.com/ | sudo sh

As the end of the log suggests, add your user to the docker group. This will require you to logoff in order to apply the change.
You can either close the WSL console window and open a new one (logoff / login), or a small trick is to "login again" using the "su" command:
client:~$ sudo usermod -aG docker $LOGNAME

client:~$ sudo su - $LOGNAME

Generate Docker client certification

As the Docker daemon is configured to only accept TLS connections from clients, the next step is to configure our client with the SSL certificates.
Before I start, I would point out there's two different paths:

  • Generate the client certificate on the server
    OR
  • Copy all the needed files (root CA, CAKey) to the client and generate it there

Even if the CAkey as a password, I'm really not fond of copying it to the client (even if it's my own computer).
So, in my case, I will generate the client certificate on the Server VM, and then copy the files back to my client (source).
Open your Hyper-V manager and connect to your Server VM:
PS> ubuntu.exe

server:~$ cd /mnt/c/Program\ Files/docker/certs

server:certs$ openssl genrsa -out key.pem 4096

server:certs$ openssl req -subj '/CN=client' -new -key key.pem -out client.csr

server:certs$ echo extendedKeyUsage = clientAuth >> client-extfile.cnf

server:certs$ openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile client-extfile.cnf

Configure Docker client

Finally, the only remaining point is to copy the needed files to the client.
Once again, there is plenty options out there, and one more time I choose the WSL way (yeah, at this stage I can be considered maniac I guess).

Note: the following steps will require that you have SSH installed on WSL inside your Server VM. Please follow this guide to so.

Get back to your WSL console on the Windows 10 client:
client:~$ mkdir .docker && cd .docker

client:.docker$ scp <server name>:"/mnt/c/Program\ Files/docker/certs/{ca,cert,key}.pem" .

client:.docker$ ls -l

client:.docker$ cd

client:~$ export DOCKER_HOST=tcp://<server name>:2376

client:~$ export DOCKER_TLS_VERIFY=1

client:~$ export DOCKER_CERT_PATH=$HOME/.docker

client:~$ env | grep DOCKER

Testing LCOW

Finally, after all the Hyper-V, Server VM and Docker (server & client) configurations, it's now time to see your efforts be rewarded.

You can follow (once again) Stefan's guide and witness by yourself how a single Docker daemon can run two different "platform based" containers:


I truly hope this guide could have helped you in some way, and once again, if you read these lines I do THANK YOU!


>>> Nunix Out <<<

Comments

Popular posts from this blog

Docker + WSL: Get 2 daemon for the price of 1

Introduction almost two years ago, Docker announced the capability of switching between the Linux and Windows containers "mode" (far from the right click that we have today). At that time, I wrote a blog post on how to run both daemons at the same time ( http://darthnunix.blogspot.ch/2016/10/docker-for-windows-2-daemons-enter-in.html ) Fast forward to 2018, and while we were blogging on how to get the TLS connection from WSL docker client with  Rory McCune  ( https://raesene.github.io/blog/2018/03/29/WSL-And-Docker/ ), another blog post, by Stefan Stranger drew my attention (read: blew my mind) as I was trying to reproduce the same: how could I "bind" the docker socket in WSL with the Docker for Windows Linux mode socket ( https://blogs.technet.microsoft.com/stefan_stranger/2018/04/02/access-my-docker-for-windows-kubernetes-cluster-from-debian-wsl/ ) From 1 to 2 daemon: DemonHunter mode achieved Now that we have all the required setup resources, let's b...

WSL: One Home to host them all

Introduction This blog post will explain how a single home mount can be shared accross all  the WSL instances. It was quite fun to find the idea and then make it happen. It will use all the tools currently available from WSL, so please don't expect a "Linux only" as Interopability will be heavily used. And before I start, here is my point of view about WSL: It's not only  Linux! It's different, just like GNU is different from Unix (yes I said it). We have finally the strength of both worlds combined. And while I do understand the "dev" aspect is meant to be reproducible in a Linux prod environment, the "ops" side is meant to take advantages of everything that can make the full environment feeling Home. Setup requirements In order to really enjoy this solution, I do recommend having 2 or more WSL distros installed or, if you fell like a real WSLCorsair, try @bketelsen crazy setup (I love it)! While the distros are downlo...

WSL + Explorer: the secret Terminal

Warning   Please note that while you should read this blog post as a "joke", which hopefully will make you smile, all the commands are technically correct and should work for you too. With that being said, let the show begin.  Introduction   During the //BUILD 2018 conference, the session with  Sarah  and  Tara  showed how far WSL has come and, lucky for us, we can now see the  replay  or if you prefer reading, Tara has your back with a  great recap .  at the very end of their presentation, there is small but (very) impactful demo: the Windows Explorer context menu now has "Open Linux shell here": Look at the past, you will see the future Unfortunately I don't remember who showed this first (I do apologize), but there's a neet trick with Windows Explorer: if you type "cmd.exe" in the address bar, it will open a command prompt in the current directory. So, with a little thinking and knowing that the shell is different fro...