kubernetes: Cannot modify registry keys during Windows pause image build process

What happened?

The Windows pause images is built using buildkit on Linux hosts and this configuration does not allow for the Windows registry to me modified during the container build process.

When Windows containers are built on Windows host machines part of the build process creates ‘delta’ registry files when get stored in the layer files. These ‘delta’ registry hive files are applied to the containers active registry when the containers are created. Chaning the registry files in the container image layers without having the ‘delta’ files present will result in the changes NOT being present in the container image.

We have an increasing demand for the ability to modify registry in the pause image on Windows such as

  • Disable some services like DiagTrack that negatively impact performance
  • Change behavior of RPCSS so it doesn’t hijack RPC port (135) for all containers in the pod

What did you expect to happen?

Things are working as expected given the current build process.

How can we reproduce it (as minimally and precisely as possible)?

There are linux utilities like chntpw that can modify Windows registry files that I have used to test this out. https://gist.github.com/marosset/f32bd81aa11527d8ba2ce8e6a62d4255 After running the container produced from these files you can see the registry changes made by chntpw persisted in the container image but these changes are not present in the container’s active registry.

C:\>reg load HKLM\mounted c:\windows\System32\config\SYSTEM
The operation completed successfully.

C:\>reg query HKLM\mounted\ControlSet001\Services\DiagTrack

HKEY_LOCAL_MACHINE\mounted\ControlSet001\Services\DiagTrack
    DependOnService    REG_MULTI_SZ    RpcSs
    Description    REG_SZ    @%SystemRoot%\system32\diagtrack.dll,-3002
    DisplayName    REG_SZ    @%SystemRoot%\system32\diagtrack.dll,-3001
    ErrorControl    REG_DWORD    0x1
    FailureActions    REG_BINARY    8051010000000000000000000300000014000000010000003075000001000000307500000000000000000000
    ImagePath    REG_EXPAND_SZ    %SystemRoot%\System32\svchost.exe -k utcsvc -p
    ObjectName    REG_SZ    LocalSystem
    RequiredPrivileges    REG_MULTI_SZ    SeChangeNotifyPrivilege\0SeCreateGlobalPrivilege\0SeAssignPrimaryTokenPrivilege\0SeImpersonatePrivilege\0SeSystemProfilePrivilege\0SeTcbPrivilege\0SeDebugPrivilege\0SeSecurityPrivilege
    ServiceSidType    REG_DWORD    0x1
    Start    REG_DWORD    0x3
    Type    REG_DWORD    0x10

vs

C:\>REG QUERY HKLM\SYSTEM\ControlSet001\Services\DiagTrack

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\DiagTrack
    DependOnService    REG_MULTI_SZ    RpcSs
    Description    REG_SZ    @%SystemRoot%\system32\diagtrack.dll,-3002
    DisplayName    REG_SZ    @%SystemRoot%\system32\diagtrack.dll,-3001
    ErrorControl    REG_DWORD    0x1
    FailureActions    REG_BINARY    8051010000000000000000000300000014000000010000003075000001000000307500000000000000000000
    ImagePath    REG_EXPAND_SZ    %SystemRoot%\System32\svchost.exe -k utcsvc -p
    ObjectName    REG_SZ    LocalSystem
    RequiredPrivileges    REG_MULTI_SZ    SeChangeNotifyPrivilege\0SeCreateGlobalPrivilege\0SeAssignPrimaryTokenPrivilege\0SeImpersonatePrivilege\0SeSystemProfilePrivilege\0SeTcbPrivilege\0SeDebugPrivilege\0SeSecurityPrivilege
    ServiceSidType    REG_DWORD    0x1
    Start    REG_DWORD    0x2
    Type    REG_DWORD    0x10

Anything else we need to know?

One possible solution is to create an intermediate image based on nanoserver (the current base image for the Windows pause image) that performs all the desired registry operations that is built on a Windows machine and published someplace (MCR maybe?) and the use that as the container base image for the Windows pause image.

Kubernetes version

N/A

Cloud provider

N/A

OS version

N/A

Install tools

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, …) and versions (if applicable)

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 18 (18 by maintainers)

Most upvoted comments

  • Continue to host the source for the intermediate layer at https://github.com/microsoft/windows-pause-image-base, publish the image to mcr.microsoft.com/oss/kubernetes/windows-pause-image-base, and then update the Windows pause build docker files in k/k to consume this image instead of the mcr.microsoft.com/windows/nanoserver

This looks more promising because this image you are creating is not a specific change for the pause container, IMO if we can change that image name to something generic and use the same wherever required.

@marosset yep. i’d expect community downstream teams (for example) would like to start with this nanoserver, have a set of dockerfiles to build this new image … then build their own pause images based on this new image