Skip to content

Latest commit

 

History

History
118 lines (76 loc) · 6.59 KB

apiserver_admission_plugins.md

File metadata and controls

118 lines (76 loc) · 6.59 KB

Admission Plugins

Similar to the kube-apiserver, the gardener-apiserver comes with a few in-tree managed admission plugins. If you want to get an overview of the what and why of admission plugins then this document might be a good start.

This document lists all existing admission plugins with a short explanation of what it is responsible for.

ClusterOpenIDConnectPreset, OpenIDConnectPreset

(both enabled by default)

These admission controllers react on CREATE operations for Shoots. If the Shoot does not specify any OIDC configuration (.spec.kubernetes.kubeAPIServer.oidcConfig=nil) then it tries to find a matching ClusterOpenIDConnectPreset or OpenIDConnectPreset, respectively. If there are multiples that match then the one with the highest weight "wins". In this case, the admission controller will default the OIDC configuration in the Shoot.

ControllerRegistrationResources

(enabled by default)

This admission controller reacts on CREATE and UPDATE operations for ControllerRegistrations. It validates that there exists only one ControllerRegistration in the system that is primarily responsible for a given kind/type resource combination. This prevents misconfiguration by the Gardener administrator/operator.

CustomVerbAuthorizer

(enabled by default)

This admission controller reacts on CREATE and UPDATE operations for Projects. It validates whether the user is bound to a RBAC role with the modify-spec-tolerations-whitelist verb in case the user tries to change the .spec.tolerations.whitelist field of the respective Project resource. Usually, regular project members are not bound to this custom verb, allowing the Gardener administrator to manage certain toleration whitelists on Project basis.

DeletionConfirmation

(enabled by default)

This admission controller reacts on DELETE operations for Projects and Shoots. It validates that the respective resource is annotated with a deletion confirmation annotation, namely confirmation.gardener.cloud/deletion=true. Only if this annotation is present it allows the DELETE operation to pass. This prevents users from accidental/undesired deletions.

ExtensionValidator

(enabled by default)

This admission controller reacts on CREATE and UPDATE operations for BackupEntrys, BackupBuckets, Seeds, and Shoots. For all the various extension types in the specifications of these objects, it validates whether there exists a ControllerRegistration in the system that is primarily responsible for the stated extension type(s). This prevents misconfigurations that would otherwise allow users to create such resources with extension types that don't exist in the cluster, effectively leading to failing reconciliation loops.

PlantValidator

(enabled by default)

This admission controller reacts on CREATE and UPDATE operations for Plants. It sets the gardener.cloud/created-by annotation for newly created Plant resources. Also, it prevents creating new Plant resources in Projects that are already have a deletion timestamp.

ResourceReferenceManager

(enabled by default)

This admission controller reacts on CREATE and UPDATE operations for CloudProfiles, Projects, SecretBindings, Seeds, and Shoots. Generally, it checks whether referred resources stated in the specifications of these objects exist in the system (e.g., if a referenced Secret exists). However, it also has some special behaviours for certain resources:

  • CloudProfiles: It rejects removing Kubernetes or machine image versions if there is at least one Shoot that refers to them.
  • Projects: It sets the .spec.createdBy field for newly created Project resources, and defaults the .spec.owner field in case it is empty (to the same value of .spec.createdBy).
  • Seeds: It rejects changing the .spec.settings.shootDNS.enabled value if there is at least one Shoot that refers to this seed.
  • Shoots: It sets the gardener.cloud/created-by=<username> annotation for newly created Shoot resources.

SeedValidator

(enabled by default)

This admission controller reacts on DELETE operations for Seeds. It checks whether the seed cluster is referenced by a BackupBucket(s) and/or Shoot(s). If any of this is true, the deletion request is rejected.

ShootDNS

(enabled by default)

This admission controller reacts on CREATE and UPDATE operations for Shoots. It tries to assign a default domain to the Shoot if it gets scheduled to a seed that enables DNS for shoots (.spec.settings.shootDNS.enabled=true). It also validates that the DNS configuration (.spec.dns) is not set if the seed disables DNS for shoots.

ShootQuotaValidator

(enabled by default)

This admission controller reacts on CREATE and UPDATE operations for Shoots. It validates the resource consumption declared in the specification against applicable Quota resources. Only if the applicable Quota resources admit the configured resources in the Shoot then it allows the request. Applicable Quotas are referred in the SecretBinding that is used by the Shoot.

ShootStateDeletionValidator

(enabled by default)

This admission controller reacts on DELETE operations for ShootStates. It prevents the deletion of the respective ShootState resource in case the corresponding Shoot resource does still exist in the system. This prevents losing the shoot's data required to recover it / migrate its control plane to a new seed cluster.

ShootTolerationRestriction

(enabled by default)

This admission controller reacts on CREATE and UPDATE operations for Shoots. It validates the .spec.tolerations used in Shoots against the whitelist of its Project, or against the whitelist configured in the admission controller's configuration, respectively. Additionally, it defaults the .spec.tolerations in Shoots with those configured in its Project, and those configured in the admission controller's configuration, respectively.

ShootValidator

(enabled by default)

This admission controller reacts on CREATE and UPDATE operations for Shoots. It validates certain configurations in the specification against the referred CloudProfile (e.g., machine images, machine types, used Kubernetes version, ...). Generally, it performs validations that cannot be handled by the static API validation due to their dynamic nature (e.g., when something needs to be checked against referred resources). Additionally, it takes over certain defaulting tasks (e.g., default machine image for worker pools).