Skip to main content

Secure nested LCOW: Part 1

The dream

Microsoft Windows and Linux working together is a today reality!
And while, my beloved, WSL is pretty much a work-in-progress, Docker and Containers are Production ready.
That's why, when Docker and Microsoft announced the public availability of Linux Containers on Windows (LCOW), the next question from the community was: what if both "platforms" could run with only one daemon.
Well, wait no more, the technology is here. Now!


Yet another guide? 

true, but believe me when I say that I followed very carefully the guides done by Docker and another by one of "my" captain, I ended several times in getting errors and no LCOW at all.
The frustration was so big that I decided to build a "new" environment step by step.
I'm nowhere near their level (I support an LMS cloud application in my day to day work), which means my setup is certainly less complex and at the same time more complicated, due to the fact I'm missing certain technical aspects here and there.

One is good, more is better

Actually, after discussing with my "first" captain, I decided to make this guide a 3 part separated as follow:
Part 1: Introduction and Windows 10 Hyper-V host configuration
Part 2: Windows 2016 Hyper-V guest and Docker daemon configuration
Part 3: Windows 10 Docker client configuration

LCOW with the usual WSL touch

of course, having a blog called "wslcorsair", I cannot have my environment without WSL, right?
And this will allow us to follow the guide for securing the Docker Daemon (part 2) thanks the one of the most useful feature: Interopability.

Starting from the end

as you should never believe everything you read on Internet, here is a short animation of the end result:


What can be shortly seen in the animation contains the following components:
  • Windows 10 (client)
    1. Hyper-V as the hypervisor
    2. WSL (ubuntu) as the SSH and Docker client
  • Windows 2016 server 1709 (server)
    1. Hyper-V as the hypervisor
    2. Docker for Windows (Server)
    3. WSL (kali) as the SSH server
One short note about the SSH Server: YES, you can use the, now official, OpenSSH feature for Windows (both 10 and 2016).
Or even better, you can do the setup directly from the Hyper-V console.
In my case, I wanted to have this "enterprise feeling", where I do not have direct access to the Hyper-V hosts and will get only Guest access.

Setup: Windows 10 Hyper-V

I will start with an important learning: do not try to go with another virtualization other than Hyper-V.
I tried virtualbox and vmware player first, and due to "nested virtualization" requirements, it always ended up in error when pulling my first image.

The reason I tried other technologies was mainly related to the network management (read NAT with Internet access).
As I'm working from a Laptop, when I setup an external network adapter on Hyper-V, it will "hijack" my Wifi network from the host and only the guest OS will have Internet access.
Not really what I need.

As for the other technologies, it didn't work well when it came to the Nested requirements (or not at all for Virtualbox).
So after long hours of Internet research, I finally found the several parts that lead to the solution, which I gladly share here:


  1. In the Hyper-V Manager console, open the Virtual Switch Manager
  2. Check the name of the NAT virtual adapter that you will use for your VM(s)
  3. Once the name confirmed, enable the Network Sharing on the host (hypervisor)
  4. Add this adapter to your VMs as a Legacy Network Adapter
  5. Finally, expose the Virtualization extensions to the VM (source)
    Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
You are now ready to install Windows 2016 VM with Hyper-V nested virtualization.
Hopefully, this first part might already help some persons getting started with a nested Hyper-v VM.

This is the end of this Part 1. I will publish the parts 2 and 3 in the next coming days.


>>> Nunix Out <<<

Comments

Popular posts from this blog

Scripting with GO: what about Windows?

!!! Warning !!!Once again, let me repeat, I'm by no means a developer nor a sysadmin (at least no more since 5 years).
This means that, while the solution below worked for me and I could reproduce it, it's not 100% safe neither!
Also, my solution still feels incomplete (read further), so if someone know the tweak to make it even more compete, please share it and reach out in Twitter, I'll be waiting.
IntroductionBy now, everyone following @jessfraz read her take about the very neat "little hack" from @cloudflareUsing Go as a scripting language in Linux

As a good WSL Corsair, I tried it and it just worked!
But then, based on my latest playground of having a seamless coding experience between WSL and Windows (thanks @bketelsen for the love and notification spam), I really thought it would be unfair to "my Windows side" to not be able enjoying the fun of GO scripting (yes, split personality is bad).

So as the good Corsair I am, it was time to see if some shinn…

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

Introductionalmost 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 achievedNow that we have all the required setup resources, let's bind them together. An…

WSL: One Home to host them all

IntroductionThis 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 requirementsIn 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 @bketelsencrazy setup (I love it)!
While the distros are downloading, let's prepare the Windo…