{
	"id": "d8f9a75c-6345-4054-846d-ca88aa2ab44e",
	"created_at": "2026-04-06T01:29:46.641288Z",
	"updated_at": "2026-04-10T03:21:53.889442Z",
	"deleted_at": null,
	"sha1_hash": "e14bf0361e350c1e8a849a7f132db31cece06ace",
	"title": "Admission Control in Kubernetes",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 216213,
	"plain_text": "Admission Control in Kubernetes\r\nBy Use caution when authoring and installing mutating webhooks\r\nArchived: 2026-04-06 00:46:44 UTC\r\nThis page provides an overview of admission controllers.\r\nAn admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to\r\npersistence of the resource, but after the request is authenticated and authorized.\r\nSeveral important features of Kubernetes require an admission controller to be enabled in order to properly\r\nsupport the feature. As a result, a Kubernetes API server that is not properly configured with the right set of\r\nadmission controllers is an incomplete server that will not support all the features you expect.\r\nWhat are they?\r\nAdmission controllers are code within the Kubernetes API server that check the data arriving in a request to\r\nmodify a resource.\r\nAdmission controllers apply to requests that create, delete, or modify objects. Admission controllers can also\r\nblock custom verbs, such as a request to connect to a pod via an API server proxy. Admission controllers do not\r\n(and cannot) block requests to read (get, watch or list) objects, because reads bypass the admission control layer.\r\nAdmission control mechanisms may be validating, mutating, or both. Mutating controllers may modify the data\r\nfor the resource being modified; validating controllers may not.\r\nThe admission controllers in Kubernetes 1.35 consist of the list below, are compiled into the kube-apiserver\r\nbinary, and may only be configured by the cluster administrator.\r\nAdmission control extension points\r\nWithin the full list, there are three special controllers: MutatingAdmissionWebhook,\r\nValidatingAdmissionWebhook, and ValidatingAdmissionPolicy. The two webhook controllers execute the\r\nmutating and validating (respectively) admission control webhooks which are configured in the API.\r\nValidatingAdmissionPolicy provides a way to embed declarative validation code within the API, without relying\r\non any external HTTP callouts.\r\nYou can use these three admission controllers to customize cluster behavior at admission time.\r\nAdmission control phases\r\nThe admission control process proceeds in two phases. In the first phase, mutating admission controllers are run.\r\nIn the second phase, validating admission controllers are run. Note again that some of the controllers are both.\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 1 of 18\n\nIf any of the controllers in either phase reject the request, the entire request is rejected immediately and an error is\r\nreturned to the end-user.\r\nFinally, in addition to sometimes mutating the object in question, admission controllers may sometimes have side\r\neffects, that is, mutate related resources as part of request processing. Incrementing quota usage is the canonical\r\nexample of why this is necessary. Any such side-effect needs a corresponding reclamation or reconciliation\r\nprocess, as a given admission controller does not know for sure that a given request will pass all of the other\r\nadmission controllers.\r\nThe ordering of these calls can be seen below.\r\nAdmission Control\r\nCalled until first rejection\r\nUser Kubernetes API Server Authentication + Authorization Mutating Webhook(s) Validating Admission Policies Validating Webhook(s)\r\nUser Kubernetes API Server Authentication + Authorization Mutating Webhook(s) Validating Admission Policies Validating Webhook(s)\r\nloop [For all Mutating Webhooks]\r\nloop [For all Validating Policies]\r\npar [For all Validating Webhooks in parallel]\r\nRequest (e.g., create a pod)\r\nAuthenticate user and\r\ncheck user permissions\r\nInvoke Mutating Webhooks\r\nModify or reject object (if needed)\r\nInvoke Validating Policies\r\nReject object (if needed)\r\nInvoke Validating Webhooks\r\nReject object (if needed)\r\nAllow or reject request\r\nResponse (e.g., success or error)\r\nWhy do I need them?\r\nSeveral important features of Kubernetes require an admission controller to be enabled in order to properly\r\nsupport the feature. As a result, a Kubernetes API server that is not properly configured with the right set of\r\nadmission controllers is an incomplete server and will not support all the features you expect.\r\nHow do I turn on an admission controller?\r\nThe Kubernetes API server flag enable-admission-plugins takes a comma-delimited list of admission control\r\nplugins to invoke prior to modifying objects in the cluster. For example, the following command line enables the\r\nNamespaceLifecycle and the LimitRanger admission control plugins:\r\nkube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...\r\nNote:\r\nDepending on the way your Kubernetes cluster is deployed and how the API server is started, you may need to\r\napply the settings in different ways. For example, you may have to modify the systemd unit file if the API server\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 2 of 18\n\nis deployed as a systemd service, you may modify the manifest file for the API server if Kubernetes is deployed in\r\na self-hosted way.\r\nHow do I turn off an admission controller?\r\nThe Kubernetes API server flag disable-admission-plugins takes a comma-delimited list of admission control\r\nplugins to be disabled, even if they are in the list of plugins enabled by default.\r\nkube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...\r\nWhich plugins are enabled by default?\r\nTo see which admission plugins are enabled:\r\nkube-apiserver -h | grep enable-admission-plugins\r\nIn Kubernetes 1.35, the default ones are:\r\nCertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClas\r\nWhat does each admission controller do?\r\nAlwaysAdmit\r\nFEATURE STATE: Kubernetes v1.13 [deprecated]\r\nType: Validating.\r\nThis admission controller allows all pods into the cluster. It is deprecated because its behavior is the same as if\r\nthere were no admission controller at all.\r\nAlwaysDeny\r\nFEATURE STATE: Kubernetes v1.13 [deprecated]\r\nType: Validating.\r\nRejects all requests. AlwaysDeny is deprecated as it has no real meaning.\r\nAlwaysPullImages\r\nType: Mutating and Validating.\r\nThis admission controller modifies every new Pod to force the image pull policy to Always . This is useful in a\r\nmultitenant cluster so that users can be assured that their private images can only be used by those who have the\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 3 of 18\n\ncredentials to pull them. Without this admission controller, once an image has been pulled to a node, any pod from\r\nany user can use it by knowing the image's name (assuming the Pod is scheduled onto the right node), without any\r\nauthorization check against the image. When this admission controller is enabled, images are always pulled prior\r\nto starting containers, which means valid credentials are required.\r\nCertificateApproval\r\nType: Validating.\r\nThis admission controller observes requests to approve CertificateSigningRequest resources and performs\r\nadditional authorization checks to ensure the approving user has permission to approve certificate requests with\r\nthe spec.signerName requested on the CertificateSigningRequest resource.\r\nSee Certificate Signing Requests for more information on the permissions required to perform different actions on\r\nCertificateSigningRequest resources.\r\nCertificateSigning\r\nType: Validating.\r\nThis admission controller observes updates to the status.certificate field of CertificateSigningRequest\r\nresources and performs an additional authorization checks to ensure the signing user has permission to sign\r\ncertificate requests with the spec.signerName requested on the CertificateSigningRequest resource.\r\nSee Certificate Signing Requests for more information on the permissions required to perform different actions on\r\nCertificateSigningRequest resources.\r\nCertificateSubjectRestriction\r\nType: Validating.\r\nThis admission controller observes creation of CertificateSigningRequest resources that have a spec.signerName\r\nof kubernetes.io/kube-apiserver-client . It rejects any request that specifies a 'group' (or 'organization\r\nattribute') of system:masters .\r\nDefaultIngressClass\r\nType: Mutating.\r\nThis admission controller observes creation of Ingress objects that do not request any specific ingress class and\r\nautomatically adds a default ingress class to them. This way, users that do not request any special ingress class do\r\nnot need to care about them at all and they will get the default one.\r\nThis admission controller does not do anything when no default ingress class is configured. When more than one\r\ningress class is marked as default, it rejects any creation of Ingress with an error and an administrator must\r\nrevisit their IngressClass objects and mark only one as default (with the annotation\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 4 of 18\n\n\"ingressclass.kubernetes.io/is-default-class\"). This admission controller ignores any Ingress updates; it acts\r\nonly on creation.\r\nSee the Ingress documentation for more about ingress classes and how to mark one as default.\r\nDefaultStorageClass\r\nType: Mutating.\r\nThis admission controller observes creation of PersistentVolumeClaim objects that do not request any specific\r\nstorage class and automatically adds a default storage class to them. This way, users that do not request any\r\nspecial storage class do not need to care about them at all and they will get the default one.\r\nThis admission controller does nothing when no default StorageClass exists. When more than one storage class\r\nis marked as default, and you then create a PersistentVolumeClaim with no storageClassName set, Kubernetes\r\nuses the most recently created default StorageClass . When a PersistentVolumeClaim is created with a\r\nspecified volumeName , it remains in a pending state if the static volume's storageClassName does not match the\r\nstorageClassName on the PersistentVolumeClaim after any default StorageClass is applied to it. This\r\nadmission controller ignores any PersistentVolumeClaim updates; it acts only on creation.\r\nSee persistent volume documentation about persistent volume claims and storage classes and how to mark a\r\nstorage class as default.\r\nDefaultTolerationSeconds\r\nType: Mutating.\r\nThis admission controller sets the default forgiveness toleration for pods to tolerate the taints\r\nnotready:NoExecute and unreachable:NoExecute based on the k8s-apiserver input parameters default-not-ready-toleration-seconds and default-unreachable-toleration-seconds if the pods don't already have\r\ntoleration for taints node.kubernetes.io/not-ready:NoExecute or\r\nnode.kubernetes.io/unreachable:NoExecute . The default value for default-not-ready-toleration-seconds\r\nand default-unreachable-toleration-seconds is 5 minutes.\r\nDenyServiceExternalIPs\r\nType: Validating.\r\nThis admission controller rejects all net-new usage of the Service field externalIPs . This feature is very\r\npowerful (allows network traffic interception) and not well controlled by policy. When enabled, users of the\r\ncluster may not create new Services which use externalIPs and may not add new values to externalIPs on\r\nexisting Service objects. Existing uses of externalIPs are not affected, and users may remove values from\r\nexternalIPs on existing Service objects.\r\nMost users do not need this feature at all, and cluster admins should consider disabling it. Clusters that do need to\r\nuse this feature should consider using some custom policy to manage usage of it.\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 5 of 18\n\nThis admission controller is disabled by default.\r\nEventRateLimit\r\nFEATURE STATE: Kubernetes v1.13 [alpha]\r\nType: Validating.\r\nThis admission controller mitigates the problem where the API server gets flooded by requests to store new\r\nEvents. The cluster admin can specify event rate limits by:\r\nEnabling the EventRateLimit admission controller;\r\nReferencing an EventRateLimit configuration file from the file provided to the API server's command\r\nline flag --admission-control-config-file :\r\napiVersion: apiserver.config.k8s.io/v1\r\nkind: AdmissionConfiguration\r\nplugins:\r\n - name: EventRateLimit\r\n path: eventconfig.yaml\r\n...\r\nThere are four types of limits that can be specified in the configuration:\r\nServer : All Event requests (creation or modifications) received by the API server share a single bucket.\r\nNamespace : Each namespace has a dedicated bucket.\r\nUser : Each user is allocated a bucket.\r\nSourceAndObject : A bucket is assigned by each combination of source and involved object of the event.\r\nBelow is a sample eventconfig.yaml for such a configuration:\r\napiVersion: eventratelimit.admission.k8s.io/v1alpha1\r\nkind: Configuration\r\nlimits:\r\n - type: Namespace\r\n qps: 50\r\n burst: 100\r\n cacheSize: 2000\r\n - type: User\r\n qps: 10\r\n burst: 50\r\nSee the EventRateLimit Config API (v1alpha1) for more details.\r\nThis admission controller is disabled by default.\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 6 of 18\n\nExtendedResourceToleration\r\nType: Mutating.\r\nThis plug-in facilitates creation of dedicated nodes with extended resources. If operators want to create dedicated\r\nnodes with extended resources (like GPUs, FPGAs etc.), they are expected to taint the node with the extended\r\nresource name as the key. This admission controller, if enabled, automatically adds tolerations for such taints to\r\npods requesting extended resources, so users don't have to manually add these tolerations.\r\nThis admission controller is disabled by default.\r\nImagePolicyWebhook\r\nType: Validating.\r\nThe ImagePolicyWebhook admission controller allows a backend webhook to make admission decisions.\r\nThis admission controller is disabled by default.\r\nConfiguration file format\r\nImagePolicyWebhook uses a configuration file to set options for the behavior of the backend. This file may be\r\njson or yaml and has the following format:\r\nimagePolicy:\r\n kubeConfigFile: /path/to/kubeconfig/for/backend\r\n # time in s to cache approval\r\n allowTTL: 50\r\n # time in s to cache denial\r\n denyTTL: 50\r\n # time in ms to wait between retries\r\n retryBackoff: 500\r\n # determines behavior if the webhook backend fails\r\n defaultAllow: true\r\nReference the ImagePolicyWebhook configuration file from the file provided to the API server's command line\r\nflag --admission-control-config-file :\r\napiVersion: apiserver.config.k8s.io/v1\r\nkind: AdmissionConfiguration\r\nplugins:\r\n - name: ImagePolicyWebhook\r\n path: imagepolicyconfig.yaml\r\n...\r\nAlternatively, you can embed the configuration directly in the file:\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 7 of 18\n\napiVersion: apiserver.config.k8s.io/v1\r\nkind: AdmissionConfiguration\r\nplugins:\r\n - name: ImagePolicyWebhook\r\n configuration:\r\n imagePolicy:\r\n kubeConfigFile: \u003cpath-to-kubeconfig-file\u003e\r\n allowTTL: 50\r\n denyTTL: 50\r\n retryBackoff: 500\r\n defaultAllow: true\r\nThe ImagePolicyWebhook config file must reference a kubeconfig formatted file which sets up the connection to\r\nthe backend. It is required that the backend communicate over TLS.\r\nThe kubeconfig file's cluster field must point to the remote service, and the user field must contain the\r\nreturned authorizer.\r\n# clusters refers to the remote service.\r\nclusters:\r\n - name: name-of-remote-imagepolicy-service\r\n cluster:\r\n certificate-authority: /path/to/ca.pem # CA for verifying the remote service.\r\n server: https://images.example.com/policy # URL of remote service to query. Must use 'https'.\r\n# users refers to the API server's webhook configuration.\r\nusers:\r\n - name: name-of-api-server\r\n user:\r\n client-certificate: /path/to/cert.pem # cert for the webhook admission controller to use\r\n client-key: /path/to/key.pem # key matching the cert\r\nFor additional HTTP configuration, refer to the kubeconfig documentation.\r\nRequest payloads\r\nWhen faced with an admission decision, the API Server POSTs a JSON serialized\r\nimagepolicy.k8s.io/v1alpha1 ImageReview object describing the action. This object contains fields describing\r\nthe containers being admitted, as well as any pod annotations that match *.image-policy.k8s.io/* .\r\nNote:\r\nThe webhook API objects are subject to the same versioning compatibility rules as other Kubernetes API objects.\r\nImplementers should be aware of looser compatibility promises for alpha objects and check the apiVersion field\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 8 of 18\n\nof the request to ensure correct deserialization. Additionally, the API Server must enable the\r\nimagepolicy.k8s.io/v1alpha1 API extensions group ( --runtime-config=imagepolicy.k8s.io/v1alpha1=true ).\r\nAn example request body:\r\n{\r\n \"apiVersion\": \"imagepolicy.k8s.io/v1alpha1\",\r\n \"kind\": \"ImageReview\",\r\n \"spec\": {\r\n \"containers\": [\r\n {\r\n \"image\": \"myrepo/myimage:v1\"\r\n },\r\n {\r\n \"image\": \"myrepo/myimage@sha256:beb6bd6a68f114c1dc2ea4b28db81bdf91de202a9014972bec5e4d9171d90ed\"\r\n }\r\n ],\r\n \"annotations\": {\r\n \"mycluster.image-policy.k8s.io/ticket-1234\": \"break-glass\"\r\n },\r\n \"namespace\": \"mynamespace\"\r\n }\r\n}\r\nThe remote service is expected to fill the status field of the request and respond to either allow or disallow\r\naccess. The response body's spec field is ignored, and may be omitted. A permissive response would return:\r\n{\r\n \"apiVersion\": \"imagepolicy.k8s.io/v1alpha1\",\r\n \"kind\": \"ImageReview\",\r\n \"status\": {\r\n \"allowed\": true\r\n }\r\n}\r\nTo disallow access, the service would return:\r\n{\r\n \"apiVersion\": \"imagepolicy.k8s.io/v1alpha1\",\r\n \"kind\": \"ImageReview\",\r\n \"status\": {\r\n \"allowed\": false,\r\n \"reason\": \"image currently blacklisted\"\r\n }\r\n}\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 9 of 18\n\nFor further documentation refer to the imagepolicy.v1alpha1 API.\r\nExtending with Annotations\r\nAll annotations on a Pod that match *.image-policy.k8s.io/* are sent to the webhook. Sending annotations\r\nallows users who are aware of the image policy backend to send extra information to it, and for different backends\r\nimplementations to accept different information.\r\nExamples of information you might put here are:\r\nrequest to \"break glass\" to override a policy, in case of emergency.\r\na ticket number from a ticket system that documents the break-glass request\r\nprovide a hint to the policy server as to the imageID of the image being provided, to save it a lookup\r\nIn any case, the annotations are provided by the user and are not validated by Kubernetes in any way.\r\nLimitPodHardAntiAffinityTopology\r\nType: Validating.\r\nThis admission controller denies any pod that defines AntiAffinity topology key other than\r\nkubernetes.io/hostname in requiredDuringSchedulingRequiredDuringExecution .\r\nThis admission controller is disabled by default.\r\nLimitRanger\r\nType: Mutating and Validating.\r\nThis admission controller will observe the incoming request and ensure that it does not violate any of the\r\nconstraints enumerated in the LimitRange object in a Namespace . If you are using LimitRange objects in your\r\nKubernetes deployment, you MUST use this admission controller to enforce those constraints. LimitRanger can\r\nalso be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger\r\napplies a 0.1 CPU requirement to all Pods in the default namespace.\r\nSee the LimitRange API reference and the example of LimitRange for more details.\r\nMutatingAdmissionWebhook\r\nType: Mutating.\r\nThis admission controller calls any mutating webhooks which match the request. Matching webhooks are called in\r\nserial; each one may modify the object if it desires.\r\nThis admission controller (as implied by the name) only runs in the mutating phase.\r\nIf a webhook called by this has side effects (for example, decrementing quota) it must have a reconciliation\r\nsystem, as it is not guaranteed that subsequent webhooks or validating admission controllers will permit the\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 10 of 18\n\nrequest to finish.\r\nIf you disable the MutatingAdmissionWebhook, you must also disable the MutatingWebhookConfiguration\r\nobject in the admissionregistration.k8s.io/v1 group/version via the --runtime-config flag, both are on by\r\ndefault.\r\nUsers may be confused when the objects they try to create are different from what they get back.\r\nBuilt in control loops may break when the objects they try to create are different when read back.\r\nSetting originally unset fields is less likely to cause problems than overwriting fields set in the\r\noriginal request. Avoid doing the latter.\r\nFuture changes to control loops for built-in resources or third-party resources may break webhooks that\r\nwork well today. Even when the webhook installation API is finalized, not all possible webhook behaviors\r\nwill be guaranteed to be supported indefinitely.\r\nNamespaceAutoProvision\r\nType: Mutating.\r\nThis admission controller examines all incoming requests on namespaced resources and checks if the referenced\r\nnamespace does exist. It creates a namespace if it cannot be found. This admission controller is useful in\r\ndeployments that do not want to restrict creation of a namespace prior to its usage.\r\nNamespaceExists\r\nType: Validating.\r\nThis admission controller checks all requests on namespaced resources other than Namespace itself. If the\r\nnamespace referenced from a request doesn't exist, the request is rejected.\r\nNamespaceLifecycle\r\nType: Validating.\r\nThis admission controller enforces that a Namespace that is undergoing termination cannot have new objects\r\ncreated in it, and ensures that requests in a non-existent Namespace are rejected. This admission controller also\r\nprevents deletion of three system reserved namespaces default , kube-system , kube-public .\r\nA Namespace deletion kicks off a sequence of operations that remove all objects (pods, services, etc.) in that\r\nnamespace. In order to enforce integrity of that process, we strongly recommend running this admission\r\ncontroller.\r\nNodeDeclaredFeatureValidator\r\nFEATURE STATE: Kubernetes v1.35 [alpha] (disabled by default)\r\nType: Validating.\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 11 of 18\n\nThis admission controller intercepts writes to bound Pods, to ensure that the changes are compatible with the\r\nfeatures declared by the node where the Pod is currently running. It uses the .status.declaredFeatures field of\r\nthe Node to determine the set of enabled features. If a Pod update requires a feature that is not listed in the features\r\nof its current node, the admission controller will reject the update request. This prevents runtime failures due to\r\nfeature mismatch after a Pod has been scheduled.\r\nThis admission controller is enabled by default if the NodeDeclaredFeatures feature gate is enabled.\r\nNodeRestriction\r\nType: Validating.\r\nThis admission controller limits the Node and Pod objects a kubelet can modify. In order to be limited by this\r\nadmission controller, kubelets must use credentials in the system:nodes group, with a username in the form\r\nsystem:node:\u003cnodeName\u003e . Such kubelets will only be allowed to modify their own Node API object, and only\r\nmodify Pod API objects that are bound to their node. kubelets are not allowed to update or remove taints from\r\ntheir Node API object.\r\nThe NodeRestriction admission plugin prevents kubelets from deleting their Node API object, and enforces\r\nkubelet modification of labels under the kubernetes.io/ or k8s.io/ prefixes as follows:\r\nPrevents kubelets from adding/removing/updating labels with a node-restriction.kubernetes.io/\r\nprefix. This label prefix is reserved for administrators to label their Node objects for workload isolation\r\npurposes, and kubelets will not be allowed to modify labels with that prefix.\r\nAllows kubelets to add/remove/update these labels and label prefixes:\r\nkubernetes.io/hostname\r\nkubernetes.io/arch\r\nkubernetes.io/os\r\nbeta.kubernetes.io/instance-type\r\nnode.kubernetes.io/instance-type\r\nfailure-domain.beta.kubernetes.io/region (deprecated)\r\nfailure-domain.beta.kubernetes.io/zone (deprecated)\r\ntopology.kubernetes.io/region\r\ntopology.kubernetes.io/zone\r\nkubelet.kubernetes.io/ -prefixed labels\r\nnode.kubernetes.io/ -prefixed labels\r\nUse of any other labels under the kubernetes.io or k8s.io prefixes by kubelets is reserved, and may be\r\ndisallowed or allowed by the NodeRestriction admission plugin in the future.\r\nFuture versions may add additional restrictions to ensure kubelets have the minimal set of permissions required to\r\noperate correctly.\r\nOwnerReferencesPermissionEnforcement\r\nType: Validating.\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 12 of 18\n\nThis admission controller protects the access to the metadata.ownerReferences of an object so that only users\r\nwith delete permission to the object can change it. This admission controller also protects the access to\r\nmetadata.ownerReferences[x].blockOwnerDeletion of an object, so that only users with update permission to\r\nthe finalizers subresource of the referenced owner can change it.\r\nPersistentVolumeClaimResize\r\nFEATURE STATE: Kubernetes v1.24 [stable]\r\nType: Validating.\r\nThis admission controller implements additional validations for checking incoming PersistentVolumeClaim\r\nresize requests.\r\nEnabling the PersistentVolumeClaimResize admission controller is recommended. This admission controller\r\nprevents resizing of all claims by default unless a claim's StorageClass explicitly enables resizing by setting\r\nallowVolumeExpansion to true .\r\nFor example: all PersistentVolumeClaim s created from the following StorageClass support volume\r\nexpansion:\r\napiVersion: storage.k8s.io/v1\r\nkind: StorageClass\r\nmetadata:\r\n name: gluster-vol-default\r\nprovisioner: kubernetes.io/glusterfs\r\nparameters:\r\n resturl: \"http://192.168.10.100:8080\"\r\n restuser: \"\"\r\n secretNamespace: \"\"\r\n secretName: \"\"\r\nallowVolumeExpansion: true\r\nFor more information about persistent volume claims, see PersistentVolumeClaims.\r\nPodNodeSelector\r\nFEATURE STATE: Kubernetes v1.5 [alpha]\r\nType: Validating.\r\nThis admission controller defaults and limits what node selectors may be used within a namespace by reading a\r\nnamespace annotation and a global configuration.\r\nThis admission controller is disabled by default.\r\nConfiguration file format\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 13 of 18\n\nPodNodeSelector uses a configuration file to set options for the behavior of the backend. Note that the\r\nconfiguration file format will move to a versioned file in a future release. This file may be json or yaml and has\r\nthe following format:\r\npodNodeSelectorPluginConfig:\r\n clusterDefaultNodeSelector: name-of-node-selector\r\n namespace1: name-of-node-selector\r\n namespace2: name-of-node-selector\r\nReference the PodNodeSelector configuration file from the file provided to the API server's command line flag\r\n--admission-control-config-file :\r\napiVersion: apiserver.config.k8s.io/v1\r\nkind: AdmissionConfiguration\r\nplugins:\r\n- name: PodNodeSelector\r\n path: podnodeselector.yaml\r\n...\r\nConfiguration Annotation Format\r\nPodNodeSelector uses the annotation key scheduler.alpha.kubernetes.io/node-selector to assign node\r\nselectors to namespaces.\r\napiVersion: v1\r\nkind: Namespace\r\nmetadata:\r\n annotations:\r\n scheduler.alpha.kubernetes.io/node-selector: name-of-node-selector\r\n name: namespace3\r\nInternal Behavior\r\nThis admission controller has the following behavior:\r\n1. If the Namespace has an annotation with a key scheduler.alpha.kubernetes.io/node-selector , use its\r\nvalue as the node selector.\r\n2. If the namespace lacks such an annotation, use the clusterDefaultNodeSelector defined in the\r\nPodNodeSelector plugin configuration file as the node selector.\r\n3. Evaluate the pod's node selector against the namespace node selector for conflicts. Conflicts result in\r\nrejection.\r\n4. Evaluate the pod's node selector against the namespace-specific allowed selector defined the plugin\r\nconfiguration file. Conflicts result in rejection.\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 14 of 18\n\nNote:\r\nPodNodeSelector allows forcing pods to run on specifically labeled nodes. Also see the PodTolerationRestriction\r\nadmission plugin, which allows preventing pods from running on specifically tainted nodes.\r\nPodSecurity\r\nFEATURE STATE: Kubernetes v1.25 [stable]\r\nType: Validating.\r\nThe PodSecurity admission controller checks new Pods before they are admitted, determines if it should be\r\nadmitted based on the requested security context and the restrictions on permitted Pod Security Standards for the\r\nnamespace that the Pod would be in.\r\nSee the Pod Security Admission documentation for more information.\r\nPodSecurity replaced an older admission controller named PodSecurityPolicy.\r\nPodTolerationRestriction\r\nFEATURE STATE: Kubernetes v1.7 [alpha]\r\nType: Mutating and Validating.\r\nThe PodTolerationRestriction admission controller verifies any conflict between tolerations of a pod and the\r\ntolerations of its namespace. It rejects the pod request if there is a conflict. It then merges the tolerations annotated\r\non the namespace into the tolerations of the pod. The resulting tolerations are checked against a list of allowed\r\ntolerations annotated to the namespace. If the check succeeds, the pod request is admitted otherwise it is rejected.\r\nIf the namespace of the pod does not have any associated default tolerations or allowed tolerations annotated, the\r\ncluster-level default tolerations or cluster-level list of allowed tolerations are used instead if they are specified.\r\nTolerations to a namespace are assigned via the scheduler.alpha.kubernetes.io/defaultTolerations\r\nannotation key. The list of allowed tolerations can be added via the\r\nscheduler.alpha.kubernetes.io/tolerationsWhitelist annotation key.\r\nExample for namespace annotations:\r\napiVersion: v1\r\nkind: Namespace\r\nmetadata:\r\n name: apps-that-need-nodes-exclusively\r\n annotations:\r\n scheduler.alpha.kubernetes.io/defaultTolerations: '[{\"operator\": \"Exists\", \"effect\": \"NoSchedule\", \"key\": \"d\r\n scheduler.alpha.kubernetes.io/tolerationsWhitelist: '[{\"operator\": \"Exists\", \"effect\": \"NoSchedule\", \"key\":\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 15 of 18\n\nThis admission controller is disabled by default.\r\nPodTopologyLabels\r\nFEATURE STATE: Kubernetes v1.35 [beta] (enabled by default)\r\nType: Mutating\r\nThe PodTopologyLabels admission controller mutates the pods/binding subresources for all pods bound to a\r\nNode, adding topology labels matching those of the bound Node. This allows Node topology labels to be available\r\nas pod labels, which can be surfaced to running containers using the Downward API. The labels available as a\r\nresult of this controller are the topology.kubernetes.io/region and topology.kuberentes.io/zone labels.\r\nNote:\r\nIf any mutating admission webhook adds or modifies labels of the pods/binding subresource, these changes will\r\npropagate to pod labels as a result of this controller, overwriting labels with conflicting keys.\r\nThis admission controller is enabled when the PodTopologyLabelsAdmission feature gate is enabled.\r\nPriority\r\nType: Mutating and Validating.\r\nThe priority admission controller uses the priorityClassName field and populates the integer value of the\r\npriority. If the priority class is not found, the Pod is rejected.\r\nResourceQuota\r\nType: Validating.\r\nThis admission controller will observe the incoming request and ensure that it does not violate any of the\r\nconstraints enumerated in the ResourceQuota object in a Namespace . If you are using ResourceQuota objects\r\nin your Kubernetes deployment, you MUST use this admission controller to enforce quota constraints.\r\nSee the ResourceQuota API reference and the example of Resource Quota for more details.\r\nRuntimeClass\r\nType: Mutating and Validating.\r\nIf you define a RuntimeClass with Pod overhead configured, this admission controller checks incoming Pods.\r\nWhen enabled, this admission controller rejects any Pod create requests that have the overhead already set. For\r\nPods that have a RuntimeClass configured and selected in their .spec , this admission controller sets\r\n.spec.overhead in the Pod based on the value defined in the corresponding RuntimeClass.\r\nSee also Pod Overhead for more information.\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 16 of 18\n\nServiceAccount\r\nType: Mutating and Validating.\r\nThis admission controller implements automation for serviceAccounts. The Kubernetes project strongly\r\nrecommends enabling this admission controller. You should enable this admission controller if you intend to make\r\nany use of Kubernetes ServiceAccount objects.\r\nTo enhance the security measures around Secrets, use separate namespaces to isolate access to mounted secrets.\r\nStorageObjectInUseProtection\r\nType: Mutating.\r\nThe StorageObjectInUseProtection plugin adds the kubernetes.io/pvc-protection or kubernetes.io/pv-protection finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a\r\nuser deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed from the PVC or PV by\r\nPVC or PV Protection Controller. Refer to the Storage Object in Use Protection for more detailed information.\r\nTaintNodesByCondition\r\nType: Mutating.\r\nThis admission controller taints newly created Nodes as NotReady and NoSchedule . That tainting avoids a race\r\ncondition that could cause Pods to be scheduled on new Nodes before their taints were updated to accurately\r\nreflect their reported conditions.\r\nValidatingAdmissionPolicy\r\nType: Validating.\r\nThis admission controller implements the CEL validation for incoming matched requests. It is enabled when both\r\nfeature gate validatingadmissionpolicy and admissionregistration.k8s.io/v1alpha1 group/version are\r\nenabled. If any of the ValidatingAdmissionPolicy fails, the request fails.\r\nValidatingAdmissionWebhook\r\nType: Validating.\r\nThis admission controller calls any validating webhooks which match the request. Matching webhooks are called\r\nin parallel; if any of them rejects the request, the request fails. This admission controller only runs in the\r\nvalidation phase; the webhooks it calls may not mutate the object, as opposed to the webhooks called by the\r\nMutatingAdmissionWebhook admission controller.\r\nIf a webhook called by this has side effects (for example, decrementing quota) it must have a reconciliation\r\nsystem, as it is not guaranteed that subsequent webhooks or other validating admission controllers will permit the\r\nrequest to finish.\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 17 of 18\n\nIf you disable the ValidatingAdmissionWebhook, you must also disable the ValidatingWebhookConfiguration\r\nobject in the admissionregistration.k8s.io/v1 group/version via the --runtime-config flag.\r\nIs there a recommended set of admission controllers to use?\r\nYes. The recommended admission controllers are enabled by default (shown here), so you do not need to\r\nexplicitly specify them. You can enable additional admission controllers beyond the default set using the --\r\nenable-admission-plugins flag (order doesn't matter).\r\nLast modified February 19, 2026 at 3:34 PM PST: Fix some links in the En docs (95b7685f71)\r\nSource: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/admission-controllers\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers"
	],
	"report_names": [
		"admission-controllers"
	],
	"threat_actors": [],
	"ts_created_at": 1775438986,
	"ts_updated_at": 1775791313,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e14bf0361e350c1e8a849a7f132db31cece06ace.pdf",
		"text": "https://archive.orkl.eu/e14bf0361e350c1e8a849a7f132db31cece06ace.txt",
		"img": "https://archive.orkl.eu/e14bf0361e350c1e8a849a7f132db31cece06ace.jpg"
	}
}