Skip to content

Group Managed Service Accounts (gMSA)#

Before you enable gMSA in MKE 4, ensure that your Active Directory, DNS, and domain connectivity are fully planned and validated.

The content herein covers only the MKE 4 configuration required to enable gMSA. It does not cover Active Directory preparation or how to join Windows nodes for gMSA use.

Prerequisites#

gMSA support in MKE 4 requires a mixed-OS cluster with:

  • At least one Linux controller node.
  • At least one Linux worker node.
  • One or more Windows worker nodes that are prepared for gMSA use and that are joined to your Active Directory environment and configured as required.
  • Active Directory provisioned.
  • Raised kernel inotify limits on every Linux controller node, as detailed in Kernel tuning below.

Kernel tuning#

The gMSA admission webhook runs on the Linux controller nodes and uses inotify to monitor its TLS certificate files. If the default inotify limits on these nodes are too low, the webhook can crash at startup. As a result, the windows-gmsa addon never reaches the Deployed state, and the cluster cannot admit gMSA workloads.

Example error message, which presents within the windows-gmsa webhook Pod log:

level=error msg="error creating watcher: too many open files"
panic: runtime error: invalid memory address or nil pointer dereference

To raise the inotify limits:

  1. Edit /etc/sysctl.conf on all Linux controller nodes:

    # Required for the gMSA admission webhook to function correctly
    fs.inotify.max_user_instances = 8192
    fs.inotify.max_user_watches = 524288
    
  2. Apply the modification:

    sudo sysctl -p
    
  3. If the webhook is already crash looping, delete its Pod so that it restarts with the new limits in effect:

    kubectl delete pod -n windows-gmsa --all
    

Limitations#

  • MKE 4 only supports domain-joined gMSA.
  • gMSA depends on Windows workers, so it is supported only in mixed Linux and Windows clusters.
  • Windows nodes must be prepared for gMSA prior to MKE 4 installation.

Enable gMSA in the cluster configuration#

Note

Active Directory setup must occur before you can enable gMSA in MKE 4.

  1. Edit spec.windows.gmsa.enabled in your mke4.yaml configuration file to true, as illustrated below:

    apiVersion: mke.mirantis.com/v1alpha1
    kind: MkeConfig
    spec:
      windows:
        gmsa:
          enabled: true
    
  2. Apply the configuration to your mixed-OS cluster:

    mkectl apply -f mke4.yaml
    

MKE installs the Kubernetes components that are needed to support gMSA-backed Windows workloads in your cluster.

At this point, with gMSA enabled, you can create gMSA objects.

Deploy Windows workloads that use gMSA#

Once your MKE 4 cluster is set up to support gMSA workloads you can create any necessary GMSACredentialSpec resources, RBAC, and Windows workloads to use gMSA. For detailed examples, refer to the official Kubernetes documentation, Configure GMSA for Windows Pods and containers.