9.5. Configuration de l'admission dynamique
Cette procédure décrit les étapes de haut niveau de la configuration de l'admission dynamique. La fonctionnalité de la chaîne d'admission est étendue en configurant un plugin d'admission webhook pour appeler un serveur webhook.
Le serveur webhook est également configuré en tant que serveur API agrégé. Cela permet à d'autres composants d'OpenShift Container Platform de communiquer avec le webhook en utilisant des identifiants internes et facilite les tests à l'aide de la commande oc. En outre, cela permet un contrôle d'accès basé sur les rôles (RBAC) dans le webhook et empêche les informations sur les jetons provenant d'autres serveurs API d'être divulguées au webhook.
Conditions préalables
- Un compte OpenShift Container Platform avec un accès administrateur de cluster.
-
L'OpenShift Container Platform CLI (
oc) est installé. - Une image de conteneur de serveur de webhook publiée.
Procédure
- Construire une image de conteneur de serveur webhook et la mettre à la disposition du cluster à l'aide d'un registre d'images.
- Créez une clé et un certificat d'autorité de certification locaux et utilisez-les pour signer la demande de signature de certificat (CSR) du serveur webhook.
Créer un nouveau projet pour les ressources webhook :
$ oc new-project my-webhook-namespace 1- 1
- Notez que le serveur webhook peut s'attendre à un nom spécifique.
Définir les règles RBAC pour le service API agrégé dans un fichier appelé
rbac.yaml:apiVersion: v1 kind: List items: - apiVersion: rbac.authorization.k8s.io/v1 1 kind: ClusterRoleBinding metadata: name: auth-delegator-my-webhook-namespace roleRef: kind: ClusterRole apiGroup: rbac.authorization.k8s.io name: system:auth-delegator subjects: - kind: ServiceAccount namespace: my-webhook-namespace name: server - apiVersion: rbac.authorization.k8s.io/v1 2 kind: ClusterRole metadata: annotations: name: system:openshift:online:my-webhook-server rules: - apiGroups: - online.openshift.io resources: - namespacereservations 3 verbs: - get - list - watch - apiVersion: rbac.authorization.k8s.io/v1 4 kind: ClusterRole metadata: name: system:openshift:online:my-webhook-requester rules: - apiGroups: - admission.online.openshift.io resources: - namespacereservations 5 verbs: - create - apiVersion: rbac.authorization.k8s.io/v1 6 kind: ClusterRoleBinding metadata: name: my-webhook-server-my-webhook-namespace roleRef: kind: ClusterRole apiGroup: rbac.authorization.k8s.io name: system:openshift:online:my-webhook-server subjects: - kind: ServiceAccount namespace: my-webhook-namespace name: server - apiVersion: rbac.authorization.k8s.io/v1 7 kind: RoleBinding metadata: namespace: kube-system name: extension-server-authentication-reader-my-webhook-namespace roleRef: kind: Role apiGroup: rbac.authorization.k8s.io name: extension-apiserver-authentication-reader subjects: - kind: ServiceAccount namespace: my-webhook-namespace name: server - apiVersion: rbac.authorization.k8s.io/v1 8 kind: ClusterRole metadata: name: my-cluster-role rules: - apiGroups: - admissionregistration.k8s.io resources: - validatingwebhookconfigurations - mutatingwebhookconfigurations verbs: - get - list - watch - apiGroups: - "" resources: - namespaces verbs: - get - list - watch - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: my-cluster-role roleRef: kind: ClusterRole apiGroup: rbac.authorization.k8s.io name: my-cluster-role subjects: - kind: ServiceAccount namespace: my-webhook-namespace name: server
- 1
- Délégue l'authentification et l'autorisation à l'API du serveur webhook.
- 2
- Permet au serveur webhook d'accéder aux ressources du cluster.
- 3
- Pointe vers des ressources. Cet exemple pointe vers la ressource
namespacereservations. - 4
- Permet au serveur API agrégé de créer des examens d'admission.
- 5
- Pointe vers des ressources. Cet exemple pointe vers la ressource
namespacereservations. - 6
- Permet au serveur webhook d'accéder aux ressources du cluster.
- 7
- Liaison de rôles pour lire la configuration de la fin de l'authentification.
- 8
- Rôle de cluster par défaut et liaisons de rôle de cluster pour un serveur d'API agrégé.
Appliquer ces règles RBAC au cluster :
$ oc auth reconcile -f rbac.yaml
Créer un fichier YAML appelé
webhook-daemonset.yamlqui est utilisé pour déployer un webhook en tant que serveur daemon dans un espace de noms :apiVersion: apps/v1 kind: DaemonSet metadata: namespace: my-webhook-namespace name: server labels: server: "true" spec: selector: matchLabels: server: "true" template: metadata: name: server labels: server: "true" spec: serviceAccountName: server containers: - name: my-webhook-container 1 image: <image_registry_username>/<image_path>:<tag> 2 imagePullPolicy: IfNotPresent command: - <container_commands> 3 ports: - containerPort: 8443 4 volumeMounts: - mountPath: /var/serving-cert name: serving-cert readinessProbe: httpGet: path: /healthz port: 8443 5 scheme: HTTPS volumes: - name: serving-cert secret: defaultMode: 420 secretName: server-serving-cert- 1
- Notez que le serveur webhook peut s'attendre à un nom de conteneur spécifique.
- 2
- Pointe vers l'image d'un conteneur de serveur webhook. Remplacez
<image_registry_username>/<image_path>:<tag>par la valeur appropriée. - 3
- Spécifie les commandes d'exécution du conteneur webhook. Remplacez
<container_commands>par la valeur appropriée. - 4
- Définit le port cible au sein des pods. Cet exemple utilise le port 8443.
- 5
- Spécifie le port utilisé par la sonde de préparation. Cet exemple utilise le port 8443.
Déployer le jeu de démons :
$ oc apply -f webhook-daemonset.yaml
Définir un secret pour le signataire du certificat du service, dans un fichier YAML appelé
webhook-secret.yaml:apiVersion: v1 kind: Secret metadata: namespace: my-webhook-namespace name: server-serving-cert type: kubernetes.io/tls data: tls.crt: <server_certificate> 1 tls.key: <server_key> 2
Créer le secret :
$ oc apply -f webhook-secret.yaml
Définir un compte de service et un service dans un fichier YAML appelé
webhook-service.yaml:apiVersion: v1 kind: List items: - apiVersion: v1 kind: ServiceAccount metadata: namespace: my-webhook-namespace name: server - apiVersion: v1 kind: Service metadata: namespace: my-webhook-namespace name: server annotations: service.beta.openshift.io/serving-cert-secret-name: server-serving-cert spec: selector: server: "true" ports: - port: 443 1 targetPort: 8443 2Exposer le serveur webhook au sein du cluster :
$ oc apply -f webhook-service.yaml
Définir une définition de ressource personnalisée pour le serveur webhook, dans un fichier appelé
webhook-crd.yaml:apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: name: namespacereservations.online.openshift.io 1 spec: group: online.openshift.io 2 version: v1alpha1 3 scope: Cluster 4 names: plural: namespacereservations 5 singular: namespacereservation 6 kind: NamespaceReservation 7
- 1
- Reflète les valeurs de
CustomResourceDefinitionspecet est au format<plural>.<group>. Cet exemple utilise la ressourcenamespacereservations. - 2
- Nom du groupe de l'API REST.
- 3
- Nom de la version de l'API REST.
- 4
- Les valeurs acceptées sont
NamespacedouCluster. - 5
- Nom pluriel à inclure dans l'URL.
- 6
- Alias vu dans la sortie de
oc. - 7
- La référence pour les manifestes de ressources.
Appliquer la définition de la ressource personnalisée :
$ oc apply -f webhook-crd.yaml
Configurez également le serveur webhook en tant que serveur d'API agrégé, dans un fichier appelé
webhook-api-service.yaml:apiVersion: apiregistration.k8s.io/v1beta1 kind: APIService metadata: name: v1beta1.admission.online.openshift.io spec: caBundle: <ca_signing_certificate> 1 group: admission.online.openshift.io groupPriorityMinimum: 1000 versionPriority: 15 service: name: server namespace: my-webhook-namespace version: v1beta1- 1
- Un certificat d'autorité de certification codé en PEM qui signe le certificat de serveur utilisé par le serveur webhook. Remplacez
<ca_signing_certificate>par le certificat approprié au format base64.
Déployer le service API agrégé :
$ oc apply -f webhook-api-service.yaml
Définissez la configuration du plugin d'admission du webhook dans un fichier appelé
webhook-config.yaml. Cet exemple utilise le plugin d'admission de validation :apiVersion: admissionregistration.k8s.io/v1beta1 kind: ValidatingWebhookConfiguration metadata: name: namespacereservations.admission.online.openshift.io 1 webhooks: - name: namespacereservations.admission.online.openshift.io 2 clientConfig: service: 3 namespace: default name: kubernetes path: /apis/admission.online.openshift.io/v1beta1/namespacereservations 4 caBundle: <ca_signing_certificate> 5 rules: - operations: - CREATE apiGroups: - project.openshift.io apiVersions: - "*" resources: - projectrequests - operations: - CREATE apiGroups: - "" apiVersions: - "*" resources: - namespaces failurePolicy: Fail
- 1
- Nom de l'objet
ValidatingWebhookConfiguration. Cet exemple utilise la ressourcenamespacereservations. - 2
- Nom du webhook à appeler. Cet exemple utilise la ressource
namespacereservations. - 3
- Permet d'accéder au serveur webhook via l'API agrégée.
- 4
- URL du webhook utilisée pour les demandes d'admission. Cet exemple utilise la ressource
namespacereservation. - 5
- Un certificat d'autorité de certification codé en PEM qui signe le certificat de serveur utilisé par le serveur webhook. Remplacez
<ca_signing_certificate>par le certificat approprié au format base64.
Déployer le webhook :
$ oc apply -f webhook-config.yaml
- Vérifiez que le webhook fonctionne comme prévu. Par exemple, si vous avez configuré l'admission dynamique pour réserver des espaces de noms spécifiques, confirmez que les demandes de création de ces espaces de noms sont rejetées et que les demandes de création d'espaces de noms non réservés aboutissent.
