Accueiil
Products
OpenShift Container Platform
4.12
L'architecture
9.5. Configuration de l'admission dynamique

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


  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


  kind: ClusterRole
  metadata:
    annotations:
    name: system:openshift:online:my-webhook-server
  rules:
  - apiGroups:
    - online.openshift.io
    resources:
    - namespacereservations


    verbs:
    - get
    - list
    - watch

- apiVersion: rbac.authorization.k8s.io/v1


  kind: ClusterRole
  metadata:
    name: system:openshift:online:my-webhook-requester
  rules:
  - apiGroups:
    - admission.online.openshift.io
    resources:
    - namespacereservations


    verbs:
    - create

- apiVersion: rbac.authorization.k8s.io/v1


  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


  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


  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.yaml qui 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


        image: <image_registry_username>/<image_path>:<tag>


        imagePullPolicy: IfNotPresent
        command:
        - <container_commands>


        ports:
        - containerPort: 8443


        volumeMounts:
        - mountPath: /var/serving-cert
          name: serving-cert
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8443


            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
1
Fait référence au certificat signé du serveur webhook. Remplacez <server_certificate> par le certificat approprié au format base64.
2
Fait référence à la clé signée du serveur webhook. Remplacez <server_key> par la clé appropriée au format base64.
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


      targetPort: 8443

1: Définit le port sur lequel le service écoute. Cet exemple utilise le port 443.
2: Définit le port cible au sein des pods vers lequel le service redirige les connexions. Cet exemple utilise le port 8443.

Exposer 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 CustomResourceDefinition spec et est au format <plural>.<group>. Cet exemple utilise la ressource namespacereservations.
2
Nom du groupe de l'API REST.
3
Nom de la version de l'API REST.
4
Les valeurs acceptées sont Namespaced ou Cluster.
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>


  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


webhooks:
- name: namespacereservations.admission.online.openshift.io


  clientConfig:
    service:


      namespace: default
      name: kubernetes
      path: /apis/admission.online.openshift.io/v1beta1/namespacereservations


    caBundle: <ca_signing_certificate>


  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 ressource namespacereservations.
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.

9.5. Configuration de l'admission dynamique

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Rendre l’open source plus inclusif

À propos de Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links