Kubernetes enables a default set of admission plugins, including PodSecurity, ResourceQuota, LimitRanger, ServiceAccount and the policy and webhook plugins. Some security relevant ones, such as AlwaysPullImages, DenyServiceExternalIPs and ImagePolicyWebhook, are not on by default. Check your own API server rather than assuming.
Why the defaults matter
Admission plugins are compiled into the kube-apiserver binary and, as the documentation says, may only be configured by the cluster administrator. If you run a managed service, the provider sets many of these for you, and it may not expose every flag. If you run your own control plane, you own the list.
The default list
The Kubernetes documentation for the version it was written against lists these as enabled by default: CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionPolicy, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, PodSecurity, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy and ValidatingAdmissionWebhook.
Lists change between releases, so read the documentation page that matches your version.
The ones that matter most for deploy security
| Plugin | What it does | On by default? |
|---|---|---|
| PodSecurity | Checks new pods against Pod Security Standards set by namespace labels | Yes |
| ValidatingAdmissionPolicy | Runs CEL rules inside the API server | Yes |
| ValidatingAdmissionWebhook | Calls your external validators | Yes |
| ResourceQuota and LimitRanger | Cap and default resources per namespace | Yes |
| AlwaysPullImages | Forces image pull policy Always on every new pod | No |
| DenyServiceExternalIPs | Rejects new use of the Service externalIPs field | No |
| ImagePolicyWebhook | Lets an external backend decide on images | No, disabled by default |
PodSecurity is worth a note: the documentation says it checks pods and is stable since Kubernetes v1.25. It only does something once namespaces carry its labels, so enabled does not mean enforcing.
ImagePolicyWebhook and fail open
The documentation shows ImagePolicyWebhook's configuration, including a defaultAllow field that determines behavior if the backend fails. Set to true, a backend outage lets images through. That is a deliberate availability tradeoff, and it should be a decision, not an accident. If you enable the plugin, write down which way it fails and why.
How to check your own cluster
- On a self managed control plane, look at the kube-apiserver flags for enable-admission-plugins and disable-admission-plugins. The documentation shows that help output can list which plugins are enabled.
- On a managed service, read the provider's documentation for supported admission features, and test behavior with a dry run instead of assuming.
- List your validating and mutating webhook configurations and policies, and note which ones fail open.
- Record the result in your cluster baseline, and review it at each upgrade.
Turn it into a baseline
Make a one page table per cluster: plugins enabled, policies bound, namespaces with PodSecurity labels, webhooks and their failure behavior. Review changes to it like any other change. When someone asks how a cluster blocks risky deploys, you can answer from the table.
Where Safeguard fits
Safeguard's asset discovery and compliance and evidence automation help you keep an inventory and a record of the controls you run. The plugin list itself comes from your cluster.
Quick check
Is PodSecurity enforcing if it is enabled?
Not by itself. Namespaces need the Pod Security labels that set the level and mode.
Is ImagePolicyWebhook on by default?
No. The documentation says it is disabled by default, and its defaultAllow setting decides what happens if the backend fails.
Sources
Last reviewed: 19 October 2026.
