Now Available: HostProcess Containers for Windows in Kubernetes 1.26

The long-awaited day has arrived: HostProcess containers, the Windows counterpart to Linux privileged containers, are finally generally available in Kubernetes 1.26!

What are HostProcess Containers and Why are They Useful?

Cluster operators often face the challenge of configuring their nodes during deployment, such as installing Windows services, configuring registry keys, managing TLS certificates, making network configuration changes, or even deploying monitoring tools like the Prometheus Node-Exporter. Until now, these tasks on Windows nodes were typically performed by running PowerShell scripts via SSH or WinRM sessions and/or using the cloud provider’s management tools.

With HostProcess containers, you can accomplish all this and much more with minimal effort through native Kubernetes APIs. You can now package any payloads into the container image, mount volumes into containers at runtime, and manage them like any other Kubernetes workload. You benefit from the advantages of containerized packaging and deployment methods, coupled with reduced administrative and development costs. The days of cluster operators manually logging into Windows nodes to perform administrative tasks are over.

HostProcess containers differ significantly from regular Windows Server containers. They run directly as processes on the host with the access policies of a user you specify. HostProcess containers run either as built-in Windows system accounts or as ephemeral users within a user group you define. HostProcess containers also share the host’s network namespace and can utilize storage mounts visible to the host. In contrast, Windows Server containers are heavily isolated and exist in a separate execution namespace. Direct access to the host from a Windows Server container is explicitly not allowed by default.

How Does It Work?

Windows HostProcess containers are implemented using Windows Job Objects, marking a departure from the previous container model that used server silos. Job Objects are components of the Windows operating system that provide the ability to manage a group of processes as a group (also known as a Job) and set resource limits for the group as a whole. Job Objects are specific to the Windows operating system and are not related to the Kubernetes Job API. They do not provide process or filesystem isolation, allowing the privileged payload to view and modify the host filesystem with the desired permissions, as well as access other host resources. The init process and all processes it starts (including those explicitly started by the user) are assigned to this container’s job object. When the init process exits or receives a termination signal, all processes in the job are also prompted to exit, the job handle is closed, and the storage is unmounted.

HostProcess and Linux privileged containers enable similar scenarios but differ significantly in their implementation (hence the different naming). HostProcess containers have their own PodSecurityContext fields. Those used for configuring Linux privileged containers do not apply. Enabling privileged access to a Windows host is a fundamentally different process than on Linux, so the configuration and capabilities differ significantly. Below is a diagram detailing the overall architecture of Windows HostProcess containers:

Before stabilization, two important features were added: the ability to operate as local user accounts and a simplified method for accessing volume mounts. To learn more, read Create a Windows HostProcess Pod.

With ayedo as an experienced Kubernetes partner, you can be confident that you are well-supported in leveraging these new functionalities!

Source: Kubernetes Blog