This is not supported. It’s also not available in Dex and would likely require we contribute upstream to add this feature.

In a public doc we should just say it isn't supported. The rest of this comment was for our internal knowledge.

Explanation:
"On the roadmap" - yes, we will do it - no fixed date.
"4.x.x" - yes, we already have a date
"Not applicable" - we won't support it in MKE4.
"Need Clarification" - need more details.

STIG - on the roadmap
Docker Content Trust - not applicable for MKE4
Swarm - not applicable for MKE4
SCIM - not applicable for MKE4
Windows - on the roadmap
OpsCare Plus - 4.0.2
Offline Install - 4.0.1 - 4.02
LCM of components - 4.0.1
gMSA - not applicable for MKE4
CIS Benchmark - on the roadmap
KMS/Vault - on the roadmap
Client bundle - on the roadmap
Image prunning / Object prunnning - on the roadmap
Customer Feedback UI - need clarification
Custom Admission controller - only OPA/GK or Kyverno EE or CE - 4.0.4
Multus - 4.0.2
Cilium - 4.0.3
ETCD enhancements - on the roadmap (liimited by k0s)
Node Local DNS - 4.1
Audit Logging - on the roadmap

Now thos that do not have a date here is a descending list in priority:
Client bundle - on the roadmap
KMS/Vault - on the roadmap
Audit Logging - on the roadmap
ETCD enhancements - on the roadmap (liimited by k0s)
Image prunning / Object prunnning - on the roadmap
Windows - on the roadmap
CIS Benchmark - on the roadmap
STIG - on the roadmap

Hey @sergeymirantis - why is gMSA not applicable if Windows support is applicable? Also could you please share the data that you used to make a case for prioritizing Multus over Cilium.

@vikramhh - I think that by the time we implement Windows - we should look into dMSA which solves many security concerns of gMSA.
As for the data for Cilium / Multus - it's based purely on blunt number of requests/mentions in IDEA project. (Multus - 6 + fact that we have it in MKE3.x ... Cilium - 5)

@sergeymirantis - migrating gMSA accounts to dMSA is not supported. What would our migration story be like if we decide to not support gMSA?

Could you please share links to the blunt requests/mentions so that the MKE team can follow-up with the request originators and do a more thorough ordering than just based on mentions alone. Were you able to connect with someone deploying Multus on MKE3.x?

@vikramhh - yes I agree there is no migration path for now. This can present a certain limitation. However, gMSA presents some serious security concerns in AD heavy environments. I personally do not really know if doing a full lift-and-shift to dMSA is not a worthwhile investment.

As for the ticket numbers - I will send them to you in email. I do not think we need to overload this thread here :)

@sergeymirantis - security concerns around gMSA have been known for years, however we still had customers deploy gMSA within the last 12 months or so. Given you determined that we would not be pursuing gMSA, I was looking for data points around which we decided that these security concerns overweight maintaining support for a feature that customers are actively using while being well aware of the security risks.

As for Multus, my query was more than just the ticket numbers. Mentioning what customers are using it would help anyone perusing this thread - however if for some reason even that question must be answered in email, I am fine with that.

Sorry @vikramhh I am lost abit. So are you trying to say we need to keep gMSA support and prioritize it?
Based on my data (what I can see in JIRA and some scraps from SalesForce) - we have basically 2 customers using gMSA.. Bigger one is Abbvie, second one is Herbalife. I am not sure how deep into production gMSA really is there.

Multus main requestor is SocGen, Telstra and Nordea. Again, Multus is "already" in MKE3.x and that is why we need to prioritize it over Cilium, which is not in MKE3.x
Also Multus would be consumed by KubeVirt that we want to ship in 4.0.2 and ultimately a version of MOSK that would be built on top of MKE4 would need multus.

Please let me know what other details you want to get.

@sergeymirantis - so far as I can tell, dMSA was introduced in WS 2025. gMSA for containers has been around for 5 years+, there is nothing analogous for dMSA yet. At least two customers are using gMSA within a year of adding support for it. There is no migration path from gMSA to dMSA. Yet we are proposing to drop support for gMSA.

OTOH, Multus, a feature which has been around in MKE3 for at least as long as gMSA, and has no user so far as I can tell, is being fast-tracked. I am finding it hard to reconcile the above two. If SocGen, Telstra and Nordea are the main requesters for Multus, why are they not using it on MKE3? No issue for Multus have ever been reported - which gives credence to the fact that no one is using it. Knowing why no one is using an existing feature would be important to know if we plan to do it for MKE4 as well - and it would be even more important to know why that is so if MOSK would use it(at least we could avoid making the shortcoming due to which it is not getting used in mke3). It could be argued that this information should be factored in while scheduling it for MKE4. I am lacking such details and trying to get those from you.

@ryan and @sergeymirantis, I think the solution that is best and easiest to maintain is to build on what we already have in the Features summary at the bottom of the page, where we list MKE 3.x features that we are working to integrate in upcoming releases. Perhaps, though, instead of building another list at the bottom for features that will not be supported, instead we develop a second Features page that specifically addresses features that are not yet in the product or that will never be in the product.

Features summary (new top-level page, describes the section, etc.)
----> Available features (second-level page, offering the table content from the Feature summary).
----> Unavailable features (second-level page)

• H1 Upcoming releases (offers the list below the table on the Feature summary)
• H2 Not supported (a new list)