×

About admission plugins

Admission plugins are used to help regulate how OpenShift Container Platform 4.10 functions. Admission plugins intercept requests to the master API to validate resource requests and ensure policies are adhered to, after the request is authenticated and authorized. For example, they are commonly used to enforce security policy, resource limitations or configuration requirements.

Admission plugins run in sequence as an admission chain. If any admission plugin in the sequence rejects a request, the whole chain is aborted and an error is returned.

OpenShift Container Platform has a default set of admission plugins enabled for each resource type. These are required for proper functioning of the cluster. Admission plugins ignore resources that they are not responsible for.

In addition to the defaults, the admission chain can be extended dynamically through webhook admission plugins that call out to custom webhook servers. There are two types of webhook admission plugins: a mutating admission plugin and a validating admission plugin. The mutating admission plugin runs first and can both modify resources and validate requests. The validating admission plugin validates requests and runs after the mutating admission plugin so that modifications triggered by the mutating admission plugin can also be validated.

Calling webhook servers through a mutating admission plugin can produce side effects on resources related to the target object. In such situations, you must take steps to validate that the end result is as expected.

Dynamic admission should be used cautiously because it impacts cluster control plane operations. When calling webhook servers through webhook admission plugins in OpenShift Container Platform 4.10, ensure that you have read the documentation fully and tested for side effects of mutations. Include steps to restore resources back to their original state prior to mutation, in the event that a request does not pass through the entire admission chain.

Default admission plugins

Default validating and admission plugins are enabled in OpenShift Container Platform 4.10. These default plugins contribute to fundamental control plane functionality, such as ingress policy, cluster resource limit override and quota policy. The following lists contain the default admission plugins:

Validating admission plugins
  • LimitRanger

  • ServiceAccount

  • PodNodeSelector

  • Priority

  • PodTolerationRestriction

  • OwnerReferencesPermissionEnforcement

  • PersistentVolumeClaimResize

  • RuntimeClass

  • CertificateApproval

  • CertificateSigning

  • CertificateSubjectRestriction

  • autoscaling.openshift.io/ManagementCPUsOverride

  • authorization.openshift.io/RestrictSubjectBindings

  • scheduling.openshift.io/OriginPodNodeEnvironment

  • network.openshift.io/ExternalIPRanger

  • network.openshift.io/RestrictedEndpointsAdmission

  • image.openshift.io/ImagePolicy

  • security.openshift.io/SecurityContextConstraint

  • security.openshift.io/SCCExecRestrictions

  • route.openshift.io/IngressAdmission

  • config.openshift.io/ValidateAPIServer

  • config.openshift.io/ValidateAuthentication

  • config.openshift.io/ValidateFeatureGate

  • config.openshift.io/ValidateConsole

  • operator.openshift.io/ValidateDNS

  • config.openshift.io/ValidateImage

  • config.openshift.io/ValidateOAuth

  • config.openshift.io/ValidateProject

  • config.openshift.io/DenyDeleteClusterConfiguration

  • config.openshift.io/ValidateScheduler

  • quota.openshift.io/ValidateClusterResourceQuota

  • security.openshift.io/ValidateSecurityContextConstraints

  • authorization.openshift.io/ValidateRoleBindingRestriction

  • config.openshift.io/ValidateNetwork

  • operator.openshift.io/ValidateKubeControllerManager

  • ValidatingAdmissionWebhook

  • ResourceQuota

  • quota.openshift.io/ClusterResourceQuota

Mutating admission plugins
  • NamespaceLifecycle

  • LimitRanger

  • ServiceAccount

  • NodeRestriction

  • TaintNodesByCondition

  • PodNodeSelector

  • Priority

  • DefaultTolerationSeconds

  • PodTolerationRestriction

  • DefaultStorageClass

  • StorageObjectInUseProtection

  • RuntimeClass

  • DefaultIngressClass

  • autoscaling.openshift.io/ManagementCPUsOverride

  • scheduling.openshift.io/OriginPodNodeEnvironment

  • image.openshift.io/ImagePolicy

  • security.openshift.io/SecurityContextConstraint

  • security.openshift.io/DefaultSecurityContextConstraints

  • MutatingAdmissionWebhook

Webhook admission plugins

In addition to OpenShift Container Platform default admission plugins, dynamic admission can be implemented through webhook admission plugins that call webhook servers, to extend the functionality of the admission chain. Webhook servers are called over HTTP at defined endpoints.

There are two types of webhook admission plugins in OpenShift Container Platform:

  • During the admission process, the mutating admission plugin can perform tasks, such as injecting affinity labels.

  • At the end of the admission process, the validating admission plugin can be used to make sure an object is configured properly, for example ensuring affinity labels are as expected. If the validation passes, OpenShift Container Platform schedules the object as configured.

When an API request comes in, mutating or validating admission plugins use the list of external webhooks in the configuration and call them in parallel:

  • If all of the webhooks approve the request, the admission chain continues.

  • If any of the webhooks deny the request, the admission request is denied and the reason for doing so is based on the first denial.

  • If more than one webhook denies the admission request, only the first denial reason is returned to the user.

  • If an error is encountered when calling a webhook, the request is either denied or the webhook is ignored depending on the error policy set. If the error policy is set to Ignore, the request is unconditionally accepted in the event of a failure. If the policy is set to Fail, failed requests are denied. Using Ignore can result in unpredictable behavior for all clients.

Communication between the webhook admission plugin and the webhook server must use TLS. Generate a CA certificate and use the certificate to sign the server certificate that is used by your webhook admission server. The PEM-encoded CA certificate is supplied to the webhook admission plugin using a mechanism, such as service serving certificate secrets.

The following diagram illustrates the sequential admission chain process within which multiple webhook servers are called.