Support for Windows job containers

See kubernetes/enhancements#2288 for more background.
To avoid any confusion here the name chosen for this container type for
the cri API and the user facing k8s settings is HostProcess containers
Internally we've coined these as job containers but it's referring to the
same type of container, the cri HostProcess field being set would be our
key to fill in the JobContainer field on the runtime spec for example.

There's been asks for Windows privileged containers, or something analagous
to it, for quite some time. While in the Linux world this can be achieved just
be loosening some of the security restrictions normally in place
for containers, this isn't as easy on Windows for many reasons. There's no such
thing as just mounting in /dev for the easy example.

The model we've landed on to support something akin to privileged containers
on Windows is to keep using the container layer technology we currently use
for Windows Server and Hyper-V isolated containers, and to simply have the
runtime manage a process, or set of processes, in a job object as the container.
The work for job containers is open source and lives here:
https://github.com/microsoft/hcsshim/tree/master/internal/jobcontainers

This approach covers all of the use cases we've currently heard that privileged
containers would be useful for. Some of these include configuring network
settings, administrative tasks, viewing/manipulating storage devices, and
the ability to simplify running daemons that need host access (kube-proxy)
on Windows. Without these changes we'd likely set an annotation to specify
that the runtime should create one of these containers, which isn't ideal.

As for the one optional field, this is really the only thing that actually
differs/isn't configurable for normal Windows Server Containers. With
job containers the final writable layer (volume) for the container
is mounted on the host so it's accessible and viewable without enumerating
the volumes on the host and trying to correlate what volume is the containers.
This is contrary to Windows Server Containers, where the volume is never mounted
to a directory anywhere, although it's still accesible from the host for the
curious.

Signed-off-by: Daniel Canter <[email protected]>

config-windows.md

@@ -205,3 +205,25 @@ The following parameters can be specified:
     }
 }
 ```
+
+## <a name="configWindowsJobContainer" />JobContainer
+
+`jobContainer` is an OPTIONAL field of the Windows configuration.
+If present, the container MUST be run as a Windows job container. This is a process or set of processes in a job object that is managed by the runtime. 
+If omitted, the container MUST be run as either a Windows Server Container, or with Hyper-V isolation if `hyperv` is supplied.
+If `hyperv` and `jobContainer` are both present, the runtime MUST return an error.
+
+The following parameters can be specified:
+
+* **`volumeMountPoint`** *(string, OPTIONAL)* - specifies the path that the containers rootfs volume should be mounted to.
+    If not supplied, the runtime will create a random path for the rootfs to be mounted at.
+
+### Example
+
+```json
+"windows": {
+    "jobContainer": {
+        "rootfsMountPoint": "C:\\foo\\bar\\baz"
+    }
+}
+```

schema/config-windows.json

@@ -93,6 +93,14 @@
                         "type": "string"
                     }
                 }
+            },
+            "jobContainer": {
+                "type": "object",
+                "properties": {
+                    "rootfsMountPoint": {
+                        "type": "string"
+                    }
+                }
             }
         },
         "required": [

specs-go/config.go

@@ -489,6 +489,8 @@ type Windows struct {
 	IgnoreFlushesDuringBoot bool `json:"ignoreFlushesDuringBoot,omitempty"`
 	// HyperV contains information for running a container with Hyper-V isolation.
 	HyperV *WindowsHyperV `json:"hyperv,omitempty"`
+	// JobContainer contains information for running a Windows job container.
+	JobContainer *WindowsJobContainer `json:"jobContainer,omitempty"`
 	// Network restriction configuration.
 	Network *WindowsNetwork `json:"network,omitempty"`
 }
@@ -557,6 +559,13 @@ type WindowsHyperV struct {
 	UtilityVMPath string `json:"utilityVMPath,omitempty"`
 }
 
+// WindowsJobContainer contains information for configuring a job container on Windows.
+type WindowsJobContainer struct {
+	// RootfsMountPoint is an optional path that indicates where the containers rootfs volume should
+	// be mounted on the host.
+	RootfsMountPoint string `json:"rootfsMountPoint,omitempty"`
+}
+
 // VM contains information for virtual-machine-based containers.
 type VM struct {
 	// Hypervisor specifies hypervisor-related configuration for virtual-machine-based containers.