HostProcess containers with Hypervisor Isolation #2531
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit adds support for running HostProcess containers with hypervisor isolated workloads. Therefore, these HPCs will run as privileged processes within the UVM. Some of the key aspects of this feature are- - A pod needs to be marked privileged by passing in annotation 'microsoft.com/hostprocess-container' - Any container which has 'microsoft.com/hostprocess-container' annotation will be launched as HostProcess Container. - Other containers will be launched as normal process-isolated containers within the UVM - HPC within UVM will not have access to any network since the sandbox (UVM) does not have any network. - GCS will create the HPCs based on the specs. The behaviour is similar to existing HPCs for process-isolated case. - Annotations for Inherit user will lead to the HPC running as System user within UVM. - Annotation for custom rootfs will lead to the container filesystem being virtualized in a directory with that custom name. If not provided, `C:\hpc` is used by default. Signed-off-by: Harsh Rawat <[email protected]>
This commit adds thorough unit tests for: - IsJobContainer - IsIsolatedJobContainer These tests explicitly verify the expected behavior for Windows HostProcess containers across isolation modes and OS targets. Signed-off-by: Harsh Rawat <[email protected]>
This commit adds thorough unit tests for the updateConfigForHostProcessContainer method. We test the following functionality- - Reject privileged container in unprivileged sandbox (isolated HPC) — return error when container requests microsoft.com/hostprocess-container=true but the pod lacks it. - Allow privileged container in privileged sandbox (isolated HPC) — ensure no unexpected mutations when no passthrough annotations are present. - Block normal process-isolated container in process-isolated HPC pod — enforce constraint that all containers in a process HPC pod must also be job containers (error on mixing). - Allow normal hypervisor-isolated container in hypervisor-isolated HPC pod. - Passthrough annotations to privileged containers — propagate HostProcessInheritUser and HostProcessRootfsLocation from pod → container for: hypervisor-isolated HPC pods with privileged containers, and process-isolated HPC pods with privileged containers. - No passthrough for normal containers — verify annotations aren’t propagated when the container is non-privileged. - Set SYSTEM user for hypervisor-isolated privileged containers — when HostProcessInheritUser=true, set Process.User.Username to NT AUTHORITY\SYSTEM. - Do not change user for normal containers — ensure container user remains unchanged even if the pod has HostProcessInheritUser=true. - Force HostProcessInheritUser to "false" for normal containers — in hypervisor-isolated privileged pods, if a non-privileged container sets the inherit annotation, flip it to "false". Signed-off-by: Harsh Rawat <[email protected]>
rawahars
force-pushed
the
hpc_inboc_hcs_for_hypervisor_isolation
branch
from
76a7277 to
b56ed8c
Compare
rawahars
changed the title
jterry75
reviewed
Oct 7, 2025
| } | ||
|
|
||
| if oci.IsIsolatedJobContainer(coi.Spec) { | ||
| v2Container.ContainerType = "HostProcess" |
There was a problem hiding this comment.
This isnt a valid ContainerType in the product code. I dont think we should reuse it like this unless we get a host side change that this becomes a valid value
There was a problem hiding this comment.
ContainerType is being added to the HCS V2 schema as part of the effort to support HostProcess containers.
This PR builds on top of the other changes on HCS/GCS side.
Signed-off-by: Harsh Rawat <[email protected]>
rawahars
force-pushed
the
hpc_inboc_hcs_for_hypervisor_isolation
branch
from
b56ed8c to
e1e1b82
Compare
Signed-off-by: Harsh Rawat <[email protected]>
Signed-off-by: Harsh Rawat <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds support for running HostProcess containers with hypervisor isolation. These HPCs will run as privileged processes within the UVM. Few key aspects of this feature are-
C:\hpcis used by default.Primary changes
updateConfigForHostProcessContainermethod for handling privileged container configuration and annotation passthrough. This method enforces correct sandbox/container combinations and properly sets user and annotation values for HostProcess containers.ContainerTypeandContainerRootPath) to support HostProcess container identification and custom root filesystem locations. These are set during container creation when an isolated job container is detected.handleProcessArgsForIsolatedJobContainerto ensure that isolated job containers have their process arguments correctly prefixed withcmd /cwhen necessary, supporting bothCommandLineandArgsfields. This logic is invoked during container and exec creation.Testing Enhancements