Manifest Based Admission Control Config

[BenTheElder]

Enhancement Description

• One-line enhancement description (can be used as a release note): Config-file based admission control (webhooks + mutating and validating admission policies) for kube-apiserver.
• Kubernetes Enhancement Proposal: https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/5793-manifest-based-admission-control-config
• Discussion Link: This concept was discussed in https://docs.google.com/document/d/1xvHWJvNqxTfrB_DovJK_Xj-i443i8TVP_TPUNKq10kU/edit?pli=1&tab=t.0 (accessible via dev@kubernetes.io community mailinglist). The KEP will be raised at the next SIG meeting (2026-01-21).
• PRs by stage and milestone:
  • Alpha - v1.36
    • KEP (k/enhancements) update PR(s):
      • KEP-5793: add initial (implementable) proposal #5827
      • KEP-5793: update kep with alpha implementation #5962
    • Code (k/k) update PR(s): KEP-5793: Add manifest-based admission control config (alpha) kubernetes#137346
    • Docs (k/website) update PR(s):
      • Add docs for Manifest Based Admission Control Config alpha website#54421
      • Add blog for Manifest Based Admission Control Config alpha website#54422
  • Beta - v1.37
    • KEP (k/enhancements) update PR(s): KEP-5793: update kep for beta in v1.37 #6093
    • Code (k/k) update PR(s):
      • Implement Exclusion of Virtual Resources from Admission Webhooks kubernetes#140019
    • Docs (k/website) update(s):
      • Add docs for Manifest Based Admission Control Config beta website#56393

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

/assign bentheelder aramase
/sig api-machinery

[lmktfy]

BTW, I don't think we call it a manifest unless it defines resources that will appear in the Kubernetes API.

We have several places where are configuration files resemble manifests, but in the documentation I personally call them "configuration files".

[lmktfy]

It's an interesting point what we call it if the same ones and zeros can work as a file loaded locally and as an actual manifest. I'll comment more on the actual PR once opened, but in terms of KEP title we do already have an analogous concept, that we call static Pods.

[BenTheElder]

BTW, I don't think we call it a manifest unless it defines resources that will appear in the Kubernetes API.

We do learn towards not surfacing them in the API at least in the initial proposal, but it mostly involves existing Kubernetes API objects in a file, e.g. MAP/VAP related objects would be contained in "manifests" IE a stream of API objects on disk, as opposed to just a new component config field/file/...

We commonly refer that to "manifest" in many places, especially if it may contain more than one object (which would likely have to be the case here to support MAP/VAP).

We can bikeshed the name as it evolves.

I'll comment more on the actual PR once opened, but in terms of KEP title we do already have an analogous concept, that we call static Pods.

Yes, the KEP will discuss that. Much of the design matches static pods as the obvious prior art. It's essentially static pods for admission policy / webhookconfiguration.

Static pods are also typically at /etc/kubernetes/manifests, naming wise.

The title here was chosen to continue the title of the previously discussed high-level proposal linked in the OP. There have been discussions about the broad concept for a while now but it needs expounding into KEP form.

I haven't quite finished the KEP draft but aim to have it at next week's SIG meeting.

[jpbetz]

/label lead-opted-in
/milestone v1.36

[Rajalakshmi-Girish]

/stage alpha

[Rajalakshmi-Girish]

Hello @BenTheElder 👋, v1.36 Enhancements team here.

This is a reminder of the upcoming PRR freeze on Wednesday 4th February 2026 (AoE) / Thursday 5th February 2026, 12:00 UTC.

This enhancement is targeting stage alpha for v1.36 (correct me, if otherwise)

Here's where this enhancement currently stands:

• PR open or merged with the KEP's PRR questionnaire filled out.
• PR open or merged with kep.yaml updated with the stage, latest-milestone, and milestone struct filled out.
• PR open or merged with a PRR approval file with the PRR approver listed for the stage the KEP is targeting.

Note that the PR is not required to be approved or merged by the PRR freeze deadline. Having the PRR questionnaire filled out by the deadline will help ensure that the PRR team has enough time to review your KEP before Enhancements Freeze on Wednesday 11th February 2026 (AoE) / Thursday 12th February 2026, 12:00 UTC. For more information on the PRR process, see here.

With all the PRR freeze requirements in place, this enhancement is now marked as Tracked for PRR freeze! Please keep the issue description up-to-date with appropriate stages as well.

/label tracked/yes