Manifest-Based Admission Control [page]deterministic

referencesecurity

This page provides an overview of manifest-based admission control configuration. Manifest-based admission control lets you load [admission webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/) and CEL-based admission policies from static files on disk, rather than from the Kubernetes API. These policies are active from API server startup, operate independently of [etcd](#gloss:etcd), and can protect API-based admission resources from modification.

To use the feature, enable the `ManifestBasedAdmissionControlConfig` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/#ManifestBasedAdmissionControlConfig) and configure the `staticManifestsDir` field in the [AdmissionConfiguration](/docs/reference/config-api/apiserver-config.v1/#apiserver-k8s-io-v1-AdmissionConfiguration) file passed to the kube-apiserver via `--admission-control-config-file`.

## Why use manifest-based admission control?

Admission policies and webhooks registered through the Kubernetes API (such as ValidatingAdmissionPolicy, MutatingAdmissionPolicy, ValidatingWebhookConfiguration, and MutatingWebhookConfiguration) have several inherent limitations:

Bootstrap gap: REST-based policy enforcement requires the API objects to be created and loaded by the dynamic admission controller. Until that happens, policies are not enforced.
Self-protection gap: Admission configuration resources (such as ValidatingWebhookConfiguration) are not themselves subject to webhook admission, to prevent circular dependencies. A user with sufficient privileges can delete or modify critical admission policies.
etcd dependency: REST-based admission configurations depend on etcd availability. If etcd is unavailable or corrupted, admission policies may not load correctly.

Manifest-based admission control addresses these limitations by loading configurations from files on disk. These configurations are:

Active as soon as the API server is ready to serve requests
Not visible or changeable through the Kubernetes API
Independent of etcd availability
Able to intercept operations on API-based admission resources themselves

## Supported resource types

You can include the following resource types in manifest files. Only the `admissionregistration.k8s.io/v1` API version is supported.

| Plugin name | Supported resource types | |:------------|:------------------------| | `ValidatingAdmissionWebhook` | ValidatingWebhookConfiguration | | `MutatingAdmissionWebhook` | MutatingWebhookConfiguration | | `ValidatingAdmissionPolicy` | ValidatingAdmissionPolicy, ValidatingAdmissionPolicyBinding | | `MutatingAdmissionPolicy` | MutatingAdmissionPolicy, MutatingAdmissionPolicyBinding |

You can also use `v1.List` to wrap multiple resources of the same plugin type in a single document.

Each admission plugin's `staticManifestsDir` must only contain resource types allowed for that plugin. For example, a directory configured for the `ValidatingAdmissionPolicy` plugin can only contain ValidatingAdmissionPolicy and ValidatingAdmissionPolicyBinding resources.

## Configuring manifest-based admission control {#configuration}

To enable manifest-based admission control, you need:

1. The `ManifestBasedAdmissionControlConfig` feature gate enabled on the kube-apiserver. 1. An `AdmissionConfiguration` file with `staticManifestsDir` fields pointing to directories containing your manifest files. 1. The manifest files themselves on disk, accessible to the kube-apiserver process.

### AdmissionConfiguration

Add `staticManifestsDir` to the plugin configuration for each admission plugin that should load manifests from disk. Each plugin requires its own directory.

The `staticManifestsDir` field accepts an absolute path to a directory. All direct-children files with `.yaml`, `.yml`, or `.json` extensions in the directory are loaded. Subdirectories and files with other extensions are ignored. Glob patterns and relative p …(trimmed)