This page explains how to configure Admission Controllers in the Kubermatic Kubernetes Platform.
The Kubermatic Kubernetes Platform manages the Kubernetes API server by setting the
enable-admission-plugins flag with a comma-delimited
list of admission control plugins to be enabled during cluster creation.
In the current version, the default ones are:
NamespaceLifecycle NodeRestriction LimitRanger ServiceAccount DefaultStorageClass DefaultTolerationSeconds MutatingAdmissionWebhook ValidatingAdmissionWebhook Priority ResourceQuota
The Kubermatic Kubernetes Platform also provides two additional plugins:
PodSecurityPolicy. They can be selected in the
PodNodeSelector plugin expands an additional view for the plugin configuration.
In this view you can define selector for namespaces that have no label selector specified. This example defines the default
NodeSelector for the cluster, as well as whitelist for each namespace.
Every pod created in the
production namespace will be injected the NodeSelector
Every pod in the
development namespace will inherit the
clusterDefaultNodeSelector, in this case
In addition to the admission plugins enabled by default or enabled as a managed KKP feature, KKP supports adding a list of admission plugins through the KKP API. This is limited to admission plugins that do not need additional configuration files or flags passed to the Kubernetes API server, for example
SecurityContextDeny (which is recommended if there is no security policy enforcement (PSPs or OPA Gatekeeper) in the cluster).
Custom admission plugins cannot be validated by KKP and there is a risk of unintended consequences when enabling some admission plugins. Make sure you test and validate your list of admission plugins on test user clusters before enabling them on production environments.
This can achieved by setting or updating the field
spec.admissionPlugins in the API for cluster resources. This field is a list, so it would look something like this:
spec: admissionPlugins: - AlwaysPullImages - SecurityContextDeny