Windows Container Support for Red Hat OpenShift release notes

Previously, containers on Windows nodes were assigned a hard-coded dns server IP address (such as 172.30.0.10) based on the default subnet. This caused dns resolution to fail in certain situations. This fix removes the hard-coded dns address, and Windows containers are now assigned a valid dns server IP address that is based on the cluster dns configuration. As a result, dns resolution works as expected for Windows containers. (BZ#2020350)

Previously, the windows-exporter metrics endpoint object contained a reference to a deleted machine. This incorrect reference caused the WMCO to ignore deleted events for machines with invalid IP addresses. This bug fix removes the validation of the machine object from the event filtering, allowing the windows-exporter metrics endpoint object to correctly update when the machine is still in the Deleting phase. (BZ#2008992)

Previously, deleting the node associated with a Windows Machine object returned a reconciliation error upon restart of the Operator. This bug fix opts not to react or reconcile when the node referenced by a Windows machine in the Running state is not found within the cluster, preventing any error loop and standardizing functionality with Linux machine objects. (BZ#2009474)

Previously, certain commands being run by the WMCO in Windows VMs were not parsed correctly by PowerShell. This caused Windows VMs with PowerShell as its default SSH shell to be unable to join to a cluster as a node. The WMCO now identifies the default SSH shell of a Windows VM and runs the associated commands accordingly. This new capability allows Windows VMs with PowerShell as the default SSH shell to be configured as nodes in a cluster. (BZ#2014707)

Previously, encrypted usernames were being generated with extra tags, which caused them not to display correctly. This bug fix removes the extra tags, allowing the encrypted username to display correctly. (BZ#2016712)

Previously, the WMCO did not properly associate BYOH Windows VMs with their Node object when the VM was specified with a dns object. This caused the WMCO to attempt to configure VMs that were already fully configured. The WMCO now resolves VMs specified by a dns address when looking for an associated node. (BZ#2020648)

Previously, the WMCO used the raw user-provided instance address when creating Bring-Your-Own-Host (BYOH) Windows nodes. This caused BYOH Windows instances to not join an OpenShift Container Platform cluster. This bug fix ensures user-provided dns names resolve to valid IPv4 addresses, and that the resolved value is used when creating BYOH Windows instances. Now BYOH instances with differing hostnames and dns addresses can be configured as Windows Nodes. (BZ#1995684)

Previously, the WMCO performed direct comparisons using unresolved instance addresses when identifying instance-to-node associations. This caused BYOH Windows instances configured to join an OpenShift Container Platform cluster to be removed. This bug fix validates dns addresses by performing dns lookups of entries that are added to the windows-instances config map. Now the WMCO can properly identify configured instance-to-node relationships, preventing any premature removals of BYOH nodes. (BZ#2005126)

The file system graphs available in the web console do not display for Windows nodes. This issue is caused by changes in the file system queries, which will be fixed in a future release of WMCO. (BZ#1930347)

For clusters installed on VMware vSphere, the WMCO ignored the Deleting phase notification event, leaving incorrect node information in the windows-exporter metrics endpoint. This resulted in an invalid mapping for the Prometheus metrics endpoint. This bug has been fixed; the WMCO now recognizes the Deleting phase notification event and maps the Prometheus metrics endpoint appropriately. (BZ#1995341)

When the RunAsUser permission is set in the security context of a Linux-based pod, the projected files have the correct permissions set, including container user ownership. However, when the Windows equivalent RunAsUsername permission is set in a Windows pod, the kubelet is prevented from setting correct ownership on the files in the projected volume. This problem can get exacerbated when used in conjunction with a hostPath volume where best practices are not followed. For example, giving a pod access to the C:\var\lib\kubelet\pods\ folder results in that pod being able to access service account tokens from other pods.

Path   : Microsoft.PowerShell.Core\FileSystem::C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt
Owner  : BUILTIN\Administrators
Group  : NT AUTHORITY\SYSTEM
Access : NT AUTHORITY\SYSTEM Allow  FullControl
         BUILTIN\Administrators Allow  FullControl
         BUILTIN\Users Allow  ReadAndExecute, Synchronize
Audit  :
Sddl   : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU)