HostProcess / Privileged containers extend the Windows container model to enable a wider range of Kubernetes cluster management scenarios. HostProcess containers run directly on the host and maintain behavior and access similar to that of a regular process. HostProcess containers allow users to package and distribute management operations and functionalities that require host access while retaining versioning and deployment methods provided by containers.
A privileged DaemonSet can carry out changes or monitor a Linux host on Kubernetes but not Windows hosts. HostProcess containers are the Windows equivalent of host elevation.
Limitations
- HostProcess containers require Kubernetes 1.23 or greater.
- HostProcess containers require
containerd
1.6 or higher container runtime. - HostProcess pods can only contain HostProcess containers.
- HostProcess containers run as a process on the host.
- Filesystem isolation and Hyper-V isolation aren’t supported for HostProcess containers.
- Volume mounts are supported and are mounted under the container volume.
- A limited set of host user accounts are available for Host Process containers by default.
- Resource limits such as disk, memory, and cpu count, work the same way as fashion as processes on the host.
- Named pipe mounts and Unix domain sockets are not directly supported, but can be accessed on their host path, for example
\.pipe*
.
Run a HostProcess workload
To use HostProcess features with our deployment, set privilaged: true, hostProcess: true, and hostNetwork: true:
spec:
...
containers:
...
securityContext:
privileged: true
windowsOptions:
hostProcess: true
...
hostNetwork: true
...
To run an example workload that uses HostProcess features on an existing AKS cluster with Windows nodes, create kcdhostprocess.yaml
Use kubectl
to run the example workload:
kubectl apply -f kcdhostprocess.yaml
We should see the following output:
$ kubectl apply -f kcdhostprocess.yaml
daemonset.apps/privileged-daemonset created
We can verify our workload by using the features of HostProcess by checking the pod’s logs.
Use kubectl
to find the name of the pod in the kube-system
namespace.
$ kubectl get pods --namespace kube-system
NAME READY STATUS RESTARTS AGE
...
privileged-daemonset-12345 1/1 Running 0 2m13s
Use kubectl logs
to view the logs of the pod and verify the pod has administrator rights:
$ kubectl logs privileged-daemonset-12345 --namespace kube-system
InvalidOperation: Unable to find type [Security.Principal.WindowsPrincipal].
Process has admin rights:
Thanks for reading my article till end. I hope you learned something special today. If you enjoyed this article then please share to your friends and if you have suggestions or thoughts to share with me then please write in the comment box.