Rechercher

9.5. Configuration de l'admission dynamique

download PDF

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

  1. Construire une image de conteneur de serveur webhook et la mettre à la disposition du cluster à l'aide d'un registre d'images.
  2. 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.
  3. 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.
  4. 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é.
  5. Appliquer ces règles RBAC au cluster :

    $ oc auth reconcile -f rbac.yaml
  6. 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  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.
  7. Déployer le jeu de démons :

    $ oc apply -f webhook-daemonset.yaml
  8. 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.
  9. Créer le secret :

    $ oc apply -f webhook-secret.yaml
  10. 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  2
    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.
  11. Exposer le serveur webhook au sein du cluster :

    $ oc apply -f webhook-service.yaml
  12. 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.
  13. Appliquer la définition de la ressource personnalisée :

    $ oc apply -f webhook-crd.yaml
  14. 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.
  15. Déployer le service API agrégé :

    $ oc apply -f webhook-api-service.yaml
  16. 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 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.
  17. Déployer le webhook :

    $ oc apply -f webhook-config.yaml
  18. 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.
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.