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)
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