Central Admission Control
This feature is an Enterprise feature. See our pricing plans or contact our sales team for more information.
You must enable MutatingAdmissionWebhook and ValidatingAdmissionWebhook admission controllers to use the Central Admission Control feature. See the Kubernetes Admission Controllers Reference for details.
Centralized Admission Control is an advanced feature for cluster admins that have custom rules that they need to apply to the virtual cluster. Cluster admins can enforce Kubernetes admission webhooks that reference the host cluster or external policy services from within the virtual cluster. Examples of validating and mutating webhook based policy engines include OPA, Kyverno, and jsPolicy.
- Central Admission Control is read-only after virtual cluster creation. Admins cannot bypass or alter hooks after vCluster deployment.
- If you need the ability to modify or delete webhook configurations, do not use Central Admission Control. Instead, manually map the host policy service into the virtual cluster.
Central admission webhooks are different from the other policies:
LimitRange
andResourceQuota
resources are created and enforced on the host cluster. They do do not appear as resources in the virtual cluster.- A user could define
LimitRange
andResourceQuota
resources inside the virtual cluster, but they have full control over them and can delete them at will. - Webhooks are different because they need to be configured inside the virtual cluster in order for them to be called by the vCluster's API server.
- vCluster rewrites these definitions to point to a proxy for a host cluster service that handles webhook requests. The host may also have webhook configurations that use this service.
- A user can still install a webhook service or webhook configuration into the virtual cluster outside of this config, but it would run inside the virtual cluster like any other workload.
Example​
This example ensures that all new ConfigMap resources are sent to a mutating webhook on the host cluster.
centralAdmission:
mutatingWebhooks:
- apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
labels:
webhook.kyverno.io/managed-by: kyverno
name: kyverno-resource-mutating-webhook-cfg
webhooks:
- admissionReviewVersions:
- v1
clientConfig:
service:
name: kyverno-svc
namespace: kyverno
path: /mutate/fail
port: 443
failurePolicy: Fail
matchPolicy: Equivalent
name: mutate.kyverno.svc-fail
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values:
- kyverno
objectSelector: {}
reinvocationPolicy: IfNeeded
rules:
- apiGroups:
- ""
apiVersions:
- v1
operations:
- CREATE
resources:
- configmaps
scope: '*'
sideEffects: NoneOnDryRun
timeoutSeconds: 10
Any time a ConfigMap is created, the vCluster API server forwards the admission request to a proxy, which in turn calls the actual admission hook running in the host cluster in the kyverno
namespace.
Note that the service providing the webhooks should not rely on the real names of the objects if they are synced on the host cluster (for example, pods). The requests that will reach the host admission service holds the objects from the virtual cluster, so your policies need to be able to handle those objects.
The hook services do not require authentication as the proxy does not have access to the AdmissionConfiguration
object or the files it references. Most policy engines (like jsPolicy, Kyverno, or Gatekeeper) do not set authentication by default, so it should work with most installations.
If a user inside the virtual cluster (admin or not) tries to delete one of your admission hooks, that uses is prompted with the following error message:
kubectl delete kyverno-resource-mutating-webhook-cfg
error: the resource kyverno-resource-mutating-webhook-cfg is protected
Config reference​
centralAdmission
required object pro​
CentralAdmission defines what validating or mutating webhooks should be enforced within the virtual cluster.
centralAdmission
required object pro​validatingWebhooks
required object[] pro​
ValidatingWebhooks are validating webhooks that should be enforced in the virtual cluster
validatingWebhooks
required object[] pro​kind
required string pro​
Kind is a string value representing the REST resource this object represents.
Servers may infer this from the endpoint the client submits requests to.
kind
required string pro​apiVersion
required string pro​
APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values.
apiVersion
required string pro​metadata
required object pro​
Standard object metadata; More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.
metadata
required object pro​name
required string pro​
Name must be unique within a namespace. Is required when creating resources, although
some resources may allow a client to request the generation of an appropriate name
automatically. Name is primarily intended for creation idempotence and configuration
definition.
name
required string pro​labels
required object pro​
Map of string keys and values that can be used to organize and categorize
(scope and select) objects. May match selectors of replication controllers
and services.
labels
required object pro​annotations
required object pro​
Annotations is an unstructured key value map stored with a resource that may be
set by external tools to store and retrieve arbitrary metadata.
annotations
required object pro​webhooks
required object[] pro​
Webhooks is a list of webhooks and the affected resources and operations.
webhooks
required object[] pro​name
required string pro​
The name of the admission webhook.
Name should be fully qualified, e.g., imagepolicy.kubernetes.io, where
"imagepolicy" is the name of the webhook, and kubernetes.io is the name
of the organization.
name
required string pro​clientConfig
required object pro​
ClientConfig defines how to communicate with the hook.
clientConfig
required object pro​