- Home
- Configuration
- Group Managed Service Accounts (gMSA)
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:
-
Edit
/etc/sysctl.confon 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 -
Apply the modification:
sudo sysctl -p -
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.
-
Edit
spec.windows.gmsa.enabledin yourmke4.yamlconfiguration file totrue, as illustrated below:apiVersion: mke.mirantis.com/v1alpha1 kind: MkeConfig spec: windows: gmsa: enabled: true -
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.