7.3. Paramètres de configuration du contrôleur d'entrée

La ressource ingresscontrollers.operator.openshift.io offre les paramètres de configuration suivants.

ParamètresDescription

domain

domain est un nom DNS géré par le contrôleur d'entrée et est utilisé pour configurer plusieurs fonctions :

  • Pour la stratégie de publication des points finaux LoadBalancerService, domain est utilisé pour configurer les enregistrements DNS. Voir endpointPublishingStrategy.
  • Lors de l'utilisation d'un certificat par défaut généré, le certificat est valable pour domain et son subdomains. Voir defaultCertificate.
  • La valeur est publiée dans les statuts individuels de l'itinéraire afin que les utilisateurs sachent où cibler les enregistrements DNS externes.

La valeur domain doit être unique pour tous les contrôleurs d'entrée et ne peut pas être mise à jour.

S'il est vide, la valeur par défaut est ingress.config.openshift.io/cluster .spec.domain .

replicas

replicas est le nombre souhaité de répliques du contrôleur d'entrée. Si elle n'est pas définie, la valeur par défaut est 2.

endpointPublishingStrategy

endpointPublishingStrategy est utilisé pour publier les points d'extrémité du contrôleur d'entrée sur d'autres réseaux, permettre des intégrations d'équilibreurs de charge et fournir un accès à d'autres systèmes.

Sur GCP, AWS et Azure, vous pouvez configurer les champs endpointPublishingStrategy suivants :

  • loadBalancer.scope
  • loadBalancer.allowedSourceRanges

Si elle n'est pas définie, la valeur par défaut est basée sur infrastructure.config.openshift.io/cluster .status.platform :

  • Amazon Web Services (AWS) : LoadBalancerService (avec champ d'application externe)
  • Azure : LoadBalancerService (avec portée externe)
  • Google Cloud Platform (GCP) : LoadBalancerService (avec une portée externe)
  • Métal nu : NodePortService

  • Autre : HostNetwork

    Note

    HostNetwork possède un champ hostNetwork avec les valeurs par défaut suivantes pour les ports de liaison optionnels : httpPort: 80, httpsPort: 443, et statsPort: 1936. Avec les ports de liaison, vous pouvez déployer plusieurs contrôleurs d'entrée sur le même nœud pour la stratégie HostNetwork.

    Exemple :

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: internal
  namespace: openshift-ingress-operator
spec:
  domain: example.com
  endpointPublishingStrategy:
    type: HostNetwork
    hostNetwork:
      httpPort: 80
      httpsPort: 443
      statsPort: 1936

    Note

    Sur Red Hat OpenStack Platform (RHOSP), la stratégie de publication des points d'extrémité LoadBalancerService n'est prise en charge que si un fournisseur de cloud est configuré pour créer des moniteurs de santé. Pour RHOSP 16.1 et 16.2, cette stratégie n'est possible que si vous utilisez le fournisseur Amphora Octavia.

    Pour plus d'informations, voir la section "Setting cloud provider options" de la documentation d'installation de RHOSP.

Pour la plupart des plateformes, la valeur endpointPublishingStrategy peut être mise à jour. Sur GCP, vous pouvez configurer les champs endpointPublishingStrategy suivants :

  • loadBalancer.scope
  • loadbalancer.providerParameters.gcp.clientAccess
  • hostNetwork.protocol
  • nodePort.protocol

defaultCertificate

La valeur defaultCertificate est une référence à un secret qui contient le certificat par défaut servi par le contrôleur d'entrée. Lorsque les itinéraires ne spécifient pas leur propre certificat, c'est la valeur defaultCertificate qui est utilisée.

The secret must contain the following keys and data: * tls.crt: certificate file contents * tls.key: key file contents

S'il n'est pas défini, un certificat générique est automatiquement généré et utilisé. Le certificat est valable pour le contrôleur d'entrée domain et subdomains, et l'autorité de certification du certificat généré est automatiquement intégrée à la liste de confiance du cluster.

Le certificat en cours d'utilisation, qu'il soit généré ou spécifié par l'utilisateur, est automatiquement intégré au serveur OAuth intégré à OpenShift Container Platform.

namespaceSelector

namespaceSelector est utilisé pour filtrer l'ensemble des espaces de noms gérés par le contrôleur d'entrée. Cette fonction est utile pour la mise en place des "shards".

routeSelector

routeSelector est utilisé pour filtrer l'ensemble des routes desservies par le contrôleur d'entrée. Cette fonction est utile pour la mise en place de zones de stockage.

nodePlacement

nodePlacement permet un contrôle explicite de la programmation du contrôleur d'entrée.

Si ce n'est pas le cas, les valeurs par défaut sont utilisées.

Note

Le paramètre nodePlacement comprend deux parties, nodeSelector et tolerations. Par exemple : 

nodePlacement:
 nodeSelector:
   matchLabels:
     kubernetes.io/os: linux
 tolerations:
 - effect: NoSchedule
   operator: Exists

tlsSecurityProfile

tlsSecurityProfile spécifie les paramètres des connexions TLS pour les contrôleurs d'entrée.

Si elle n'est pas définie, la valeur par défaut est basée sur la ressource apiservers.config.openshift.io/cluster.

Lors de l'utilisation des types de profil Old, Intermediate et Modern, la configuration effective du profil est susceptible de changer entre les versions. Par exemple, compte tenu d'une spécification relative à l'utilisation du profil Intermediate déployé dans la version X.Y.Z, une mise à niveau vers la version X.Y.Z 1 peut entraîner l'application d'une nouvelle configuration de profil au contrôleur d'entrée, ce qui se traduit par un déploiement.

La version TLS minimale pour les contrôleurs d'entrée est 1.1, et la version TLS maximale est 1.3.

Note

Les codes et la version TLS minimale du profil de sécurité configuré sont reflétés dans l'état TLSProfile.

Important

L'opérateur d'entrée convertit le TLS 1.0 d'un profil Old ou Custom en 1.1.

clientTLS

clientTLS authentifie l'accès du client au cluster et aux services ; en conséquence, l'authentification mutuelle TLS est activée. S'il n'est pas défini, l'authentification TLS du client n'est pas activée.

clientTLS comporte les sous-zones requises, spec.clientTLS.clientCertificatePolicy et spec.clientTLS.ClientCA.

Le sous-champ ClientCertificatePolicy accepte l'une des deux valeurs suivantes : Required ou Optional. Le sous-champ ClientCA spécifie une carte de configuration qui se trouve dans l'espace de noms openshift-config. La carte de configuration doit contenir un paquet de certificats d'autorité de certification. Le champ AllowedSubjectPatterns est une valeur facultative qui spécifie une liste d'expressions régulières, qui sont comparées au nom distinctif d'un certificat client valide pour filtrer les demandes. Les expressions régulières doivent utiliser la syntaxe PCRE. Au moins un motif doit correspondre au nom distinctif d'un certificat client ; sinon, le contrôleur d'entrée rejette le certificat et refuse la connexion. S'il n'est pas spécifié, le contrôleur d'entrée ne rejette pas les certificats sur la base du nom distinctif.

routeAdmission

routeAdmission définit une politique de traitement des nouvelles demandes d'itinéraires, par exemple en autorisant ou en refusant les demandes entre espaces de noms.

namespaceOwnership décrit comment les demandes de noms d'hôtes dans les espaces de noms doivent être gérées. La valeur par défaut est Strict.

  • Strict: ne permet pas aux routes de revendiquer le même nom d'hôte dans plusieurs espaces de noms.
  • InterNamespaceAllowed: permet aux itinéraires de revendiquer différents chemins pour le même nom d'hôte à travers les espaces de noms.

wildcardPolicy décrit comment les routes avec des politiques de caractères génériques sont gérées par le contrôleur d'entrée.

  • WildcardsAllowed: Indique que les routes avec n'importe quelle politique de caractères génériques sont admises par le contrôleur d'entrée.
  • WildcardsDisallowed: Indique que seules les routes ayant une politique de wildcard de None sont admises par le contrôleur d'entrée. La mise à jour de wildcardPolicy de WildcardsAllowed à WildcardsDisallowed entraîne l'arrêt des itinéraires admis avec une politique de wildcard de Subdomain. Ces itinéraires doivent être recréés avec une politique de wildcard de None pour être réadmis par le contrôleur d'entrée. WildcardsDisallowed est le paramètre par défaut.

IngressControllerLogging

logging définit les paramètres de ce qui est enregistré et à quel endroit. Si ce champ est vide, les journaux opérationnels sont activés mais les journaux d'accès sont désactivés.

  • access décrit comment les demandes des clients sont enregistrées. Si ce champ est vide, l'enregistrement des accès est désactivé.

    • destination décrit une destination pour les messages du journal.

      • type est le type de destination des journaux :

        • Container spécifie que les journaux doivent être envoyés à un conteneur sidecar. L'opérateur d'ingestion configure le conteneur, nommé logs, sur le pod du contrôleur d'ingestion et configure le contrôleur d'ingestion pour qu'il écrive les journaux dans le conteneur. Il est prévu que l'administrateur configure une solution de journalisation personnalisée qui lit les journaux à partir de ce conteneur. L'utilisation de journaux de conteneurs signifie que les journaux peuvent être abandonnés si le taux de journaux dépasse la capacité d'exécution du conteneur ou la capacité de la solution de journalisation personnalisée.
        • Syslog spécifie que les journaux sont envoyés à un point de terminaison Syslog. L'administrateur doit spécifier un point de terminaison capable de recevoir des messages Syslog. L'administrateur est censé avoir configuré une instance Syslog personnalisée.
      • container décrit les paramètres du type de destination de l'enregistrement Container. Actuellement, il n'y a pas de paramètres pour la journalisation des conteneurs, ce champ doit donc être vide.

      • syslog décrit les paramètres du type de destination de la journalisation Syslog:

        • address est l'adresse IP du point de terminaison syslog qui reçoit les messages de journalisation.
        • port est le numéro de port UDP du point de terminaison syslog qui reçoit les messages de journalisation.
        • maxLength est la longueur maximale du message syslog. Elle doit être comprise entre 480 et 4096 octets. Si ce champ est vide, la longueur maximale est fixée à la valeur par défaut de 1024 bytes.
        • facility spécifie l'installation syslog des messages de journalisation. Si ce champ est vide, l'installation est local1. Sinon, il doit spécifier une installation syslog valide : kern user , mail, daemon, auth, syslog, lpr, news, uucp, cron, auth2, ftp, ntp, audit, alert, cron2, local0, local1, local2, local3. local4, local5, local6, ou local7.
    • httpLogFormat spécifie le format du message d'enregistrement pour une requête HTTP. Si ce champ est vide, les messages de journalisation utilisent le format de journalisation HTTP par défaut de l'implémentation. Pour connaître le format de journal HTTP par défaut de HAProxy, voir la documentation de HAProxy.

httpHeaders

httpHeaders définit la politique pour les en-têtes HTTP.

En définissant forwardedHeaderPolicy pour IngressControllerHTTPHeaders, vous spécifiez quand et comment le contrôleur d'entrée définit les en-têtes HTTP Forwarded, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto, et X-Forwarded-Proto-Version.

Par défaut, la politique est définie sur Append.

  • Append spécifie que le contrôleur d'entrée ajoute les en-têtes, en préservant les en-têtes existants.
  • Replace spécifie que le contrôleur d'entrée définit les en-têtes, en supprimant tous les en-têtes existants.
  • IfNone spécifie que le contrôleur d'entrée définit les en-têtes s'ils ne le sont pas déjà.
  • Never spécifie que le contrôleur d'entrée ne définit jamais les en-têtes, préservant ainsi les en-têtes existants.

En définissant headerNameCaseAdjustments, vous pouvez spécifier les corrections de casse qui peuvent être appliquées aux noms d'en-tête HTTP. Chaque correction est spécifiée sous la forme d'un nom d'en-tête HTTP avec la majuscule souhaitée. Par exemple, en spécifiant X-Forwarded-For, vous indiquez que l'en-tête HTTP x-forwarded-for doit être ajusté pour avoir la majuscule spécifiée.

Ces ajustements ne s'appliquent qu'aux itinéraires en clair, terminés par les bords et recryptés, et uniquement lors de l'utilisation du protocole HTTP/1.

Pour les en-têtes de requête, ces ajustements ne sont appliqués qu'aux itinéraires qui ont l'annotation haproxy.router.openshift.io/h1-adjust-case=true. Pour les en-têtes de réponse, ces ajustements sont appliqués à toutes les réponses HTTP. Si ce champ est vide, aucun en-tête de requête n'est ajusté.

httpCompression

httpCompression définit la politique de compression du trafic HTTP.

  • mimeTypes définit une liste de types MIME auxquels la compression doit être appliquée. Par exemple, text/css; charset=utf-8, text/html, text/*, image/svg xml, application/octet-stream, X-custom/customsub, en utilisant le modèle de format type/subtype; [;attribute=value]. Les types sont : application, image, message, multipart, texte, vidéo, ou un type personnalisé précédé de X-; par exemple. Pour voir la notation complète des types et sous-types MIME, voir RFC1341

httpErrorCodePages

httpErrorCodePages spécifie des pages de réponse personnalisées pour le code d'erreur HTTP. Par défaut, un IngressController utilise les pages d'erreur intégrées à l'image IngressController.

httpCaptureCookies

httpCaptureCookies spécifie les cookies HTTP que vous souhaitez capturer dans les journaux d'accès. Si le champ httpCaptureCookies est vide, les journaux d'accès ne capturent pas les cookies.

Pour tout cookie que vous souhaitez capturer, les paramètres suivants doivent figurer dans votre configuration IngressController:

  • name spécifie le nom du cookie.
  • maxLength spécifie la longueur maximale du cookie.
  • matchType spécifie si le champ name du cookie correspond exactement à la configuration du cookie de capture ou s'il s'agit d'un préfixe de la configuration du cookie de capture. Le champ matchType utilise les paramètres Exact et Prefix.

Par exemple : 

  httpCaptureCookies:
  - matchType: Exact
    maxLength: 128
    name: MYCOOKIE

httpCaptureHeaders

httpCaptureHeaders spécifie les en-têtes HTTP que vous souhaitez capturer dans les journaux d'accès. Si le champ httpCaptureHeaders est vide, les journaux d'accès ne capturent pas les en-têtes.

httpCaptureHeaders contient deux listes d'en-têtes à capturer dans les journaux d'accès. Les deux listes de champs d'en-tête sont request et response. Dans les deux listes, le champ name doit spécifier le nom de l'en-tête et le champ maxlength doit spécifier la longueur maximale de l'en-tête. Par exemple : 

  httpCaptureHeaders:
    request:
    - maxLength: 256
      name: Connection
    - maxLength: 128
      name: User-Agent
    response:
    - maxLength: 256
      name: Content-Type
    - maxLength: 256
      name: Content-Length

tuningOptions

tuningOptions spécifie les options permettant de régler les performances des modules de contrôle d'entrée.

  • clientFinTimeout spécifie la durée pendant laquelle une connexion reste ouverte en attendant la réponse du client à la fermeture de la connexion par le serveur. Le délai par défaut est de 1s.
  • clientTimeout spécifie la durée pendant laquelle une connexion reste ouverte dans l'attente d'une réponse du client. Le délai par défaut est de 30s.
  • headerBufferBytes spécifie la quantité de mémoire réservée, en octets, pour les sessions de connexion du contrôleur d'entrée. Cette valeur doit être au moins égale à 16384 si HTTP/2 est activé pour le contrôleur d'entrée. Si elle n'est pas définie, la valeur par défaut est 32768 bytes. Il n'est pas recommandé de définir ce champ car les valeurs headerBufferBytes trop petites peuvent casser le contrôleur d'entrée, et les valeurs headerBufferBytes trop grandes peuvent amener le contrôleur d'entrée à utiliser beaucoup plus de mémoire que nécessaire.
  • headerBufferMaxRewriteBytes spécifie la quantité de mémoire à réserver, en octets, à partir de headerBufferBytes pour la réécriture et l'ajout d'en-têtes HTTP pour les sessions de connexion du contrôleur d'entrée. La valeur minimale de headerBufferMaxRewriteBytes est 4096. headerBufferBytes doit être supérieur à headerBufferMaxRewriteBytes pour les demandes HTTP entrantes. Si ce champ n'est pas défini, la valeur par défaut est 8192 bytes. Il n'est pas recommandé de définir ce champ, car les valeurs headerBufferMaxRewriteBytes trop petites peuvent interrompre le contrôleur d'ingestion et les valeurs headerBufferMaxRewriteBytes trop grandes peuvent entraîner l'utilisation par le contrôleur d'ingestion d'une quantité de mémoire beaucoup plus importante que nécessaire.
  • healthCheckInterval spécifie la durée d'attente entre les contrôles de santé du routeur. La valeur par défaut est 5s.
  • serverFinTimeout spécifie la durée pendant laquelle une connexion reste ouverte en attendant la réponse du serveur au client qui ferme la connexion. Le délai par défaut est de 1s.
  • serverTimeout spécifie la durée pendant laquelle une connexion reste ouverte dans l'attente d'une réponse du serveur. Le délai par défaut est de 30s.
  • threadCount spécifie le nombre de threads à créer par processus HAProxy. La création d'un plus grand nombre de threads permet à chaque contrôleur d'entrée de traiter davantage de connexions, au prix d'une utilisation accrue des ressources du système. HAProxy prend en charge jusqu'à 64 threads. Si ce champ est vide, le contrôleur d'entrée utilise la valeur par défaut de 4 threads. La valeur par défaut peut changer dans les prochaines versions. La définition de ce champ n'est pas recommandée car l'augmentation du nombre de threads HAProxy permet aux modules du contrôleur d'ingérence d'utiliser davantage de temps d'unité centrale en cas de charge et d'empêcher d'autres modules de recevoir les ressources d'unité centrale dont ils ont besoin pour fonctionner. La réduction du nombre de threads peut nuire aux performances du contrôleur d'ingérence.
  • tlsInspectDelay spécifie la durée pendant laquelle le routeur peut conserver les données pour trouver un itinéraire correspondant. Si cette valeur est trop courte, le routeur peut se rabattre sur le certificat par défaut pour les itinéraires terminés par les bords, recryptés ou traversants, même s'il utilise un certificat mieux adapté. Le délai d'inspection par défaut est de 5s.
  • tunnelTimeout spécifie combien de temps une connexion au tunnel, y compris les websockets, reste ouverte lorsque le tunnel est inactif. Le délai par défaut est de 1h.

  • maxConnections indique le nombre maximal de connexions simultanées pouvant être établies par processus HAProxy. L'augmentation de cette valeur permet à chaque module de contrôleur d'entrée de gérer davantage de connexions au prix de ressources système supplémentaires. Les valeurs autorisées sont 0, -1, toute valeur comprise entre 2000 et 2000000, ou le champ peut être laissé vide.

    • Si ce champ est vide ou a la valeur 0, le contrôleur d'entrée utilisera la valeur par défaut de 50000. Cette valeur est susceptible d'être modifiée dans les versions ultérieures.
    • Si le champ a la valeur -1, HAProxy calculera dynamiquement une valeur maximale basée sur la valeur ulimits disponible dans le conteneur en cours d'exécution. Ce processus aboutit à une valeur calculée élevée qui entraîne une utilisation importante de la mémoire par rapport à la valeur par défaut actuelle de 50000.
    • Si le champ a une valeur supérieure à la limite actuelle du système d'exploitation, le processus HAProxy ne démarrera pas.
    • Si vous choisissez une valeur discrète et que le router pod est migré vers un nouveau nœud, il est possible que le nouveau nœud n'ait pas une configuration ulimit identique. Dans ce cas, le pod ne démarre pas.
    • Si vous avez configuré des nœuds avec différents ulimits et que vous choisissez une valeur discrète, il est recommandé d'utiliser la valeur -1 pour ce champ afin que le nombre maximal de connexions soit calculé au moment de l'exécution.

logEmptyRequests

logEmptyRequests spécifie les connexions pour lesquelles aucune demande n'est reçue et enregistrée. Ces requêtes vides proviennent des sondes de santé de l'équilibreur de charge ou des connexions spéculatives du navigateur web (préconnexion) et l'enregistrement de ces requêtes peut s'avérer indésirable. Cependant, ces demandes peuvent être causées par des erreurs de réseau, auquel cas l'enregistrement des demandes vides peut être utile pour diagnostiquer les erreurs. Ces demandes peuvent être causées par des balayages de ports, et l'enregistrement des demandes vides peut aider à détecter les tentatives d'intrusion. Les valeurs autorisées pour ce champ sont Log et Ignore. La valeur par défaut est Log.

Le type LoggingPolicy accepte l'une des deux valeurs suivantes :

  • Log: La valeur Log indique qu'un événement doit être enregistré.
  • Ignore: La définition de cette valeur à Ignore définit l'option dontlognull dans la configuration de HAproxy.

HTTPEmptyRequestsPolicy

HTTPEmptyRequestsPolicy décrit comment les connexions HTTP sont gérées si la connexion est interrompue avant qu'une demande ne soit reçue. Les valeurs autorisées pour ce champ sont Respond et Ignore. La valeur par défaut est Respond.

Le type HTTPEmptyRequestsPolicy accepte l'une des deux valeurs suivantes :

  • Respond: Si le champ est défini sur Respond, le contrôleur d'entrée envoie une réponse HTTP 400 ou 408, enregistre la connexion si l'enregistrement des accès est activé et comptabilise la connexion dans les paramètres appropriés.
  • Ignore: La définition de cette option sur Ignore ajoute le paramètre http-ignore-probes dans la configuration de HAproxy. Si le champ est défini sur Ignore, le contrôleur d'entrée ferme la connexion sans envoyer de réponse, puis enregistre la connexion ou incrémente les mesures.

Ces connexions proviennent de sondes de santé d'équilibreurs de charge ou de connexions spéculatives de navigateurs web (préconnexion) et peuvent être ignorées sans risque. Cependant, ces demandes peuvent être causées par des erreurs de réseau, de sorte que la définition de ce champ à Ignore peut entraver la détection et le diagnostic des problèmes. Ces demandes peuvent être causées par des balayages de ports, auquel cas l'enregistrement des demandes vides peut aider à détecter les tentatives d'intrusion.

Note

Tous les paramètres sont facultatifs.

7.3.1. Profils de sécurité TLS du contrôleur d'entrée

Les profils de sécurité TLS permettent aux serveurs de déterminer les algorithmes de chiffrement qu'un client peut utiliser lorsqu'il se connecte au serveur.

7.3.1.1. Comprendre les profils de sécurité TLS

Vous pouvez utiliser un profil de sécurité TLS (Transport Layer Security) pour définir les algorithmes TLS requis par les différents composants d'OpenShift Container Platform. Les profils de sécurité TLS d'OpenShift Container Platform sont basés sur les configurations recommandées par Mozilla.

Vous pouvez spécifier l'un des profils de sécurité TLS suivants pour chaque composant :

Tableau 7.1. Profils de sécurité TLS

ProfileDescription

Old

Ce profil est destiné à être utilisé avec des clients ou des bibliothèques anciens. Il est basé sur l'ancienne configuration recommandée pour la rétrocompatibilité.

Le profil Old nécessite une version TLS minimale de 1.0.

Note

Pour le contrôleur d'entrée, la version minimale de TLS passe de 1.0 à 1.1.

Intermediate

Ce profil est la configuration recommandée pour la majorité des clients. Il s'agit du profil de sécurité TLS par défaut pour le contrôleur d'entrée, le kubelet et le plan de contrôle. Le profil est basé sur la configuration recommandée pour la compatibilité intermédiaire.

Le profil Intermediate nécessite une version TLS minimale de 1.2.

Modern

Ce profil est destiné à être utilisé avec des clients modernes qui n'ont pas besoin de rétrocompatibilité. Ce profil est basé sur la configuration recommandée pour la compatibilité moderne.

Le profil Modern nécessite une version TLS minimale de 1.3.

Custom

Ce profil permet de définir la version de TLS et les algorithmes de chiffrement à utiliser.

Avertissement

Soyez prudent lorsque vous utilisez un profil Custom, car des configurations non valides peuvent causer des problèmes.

Note

Lorsque l'on utilise l'un des types de profil prédéfinis, la configuration effective du profil est susceptible d'être modifiée entre les versions. Par exemple, si l'on spécifie l'utilisation du profil intermédiaire déployé dans la version X.Y.Z, une mise à niveau vers la version X.Y.Z 1 peut entraîner l'application d'une nouvelle configuration de profil, ce qui se traduit par un déploiement.

7.3.1.2. Configuration du profil de sécurité TLS pour le contrôleur d'entrée

Pour configurer un profil de sécurité TLS pour un contrôleur d'entrée, modifiez la ressource personnalisée (CR) IngressController afin de spécifier un profil de sécurité TLS prédéfini ou personnalisé. Si aucun profil de sécurité TLS n'est configuré, la valeur par défaut est basée sur le profil de sécurité TLS défini pour le serveur API.

Exemple de CR IngressController qui configure le profil de sécurité TLS Old 

apiVersion: operator.openshift.io/v1
kind: IngressController
 ...
spec:
  tlsSecurityProfile:
    old: {}
    type: Old
 ...

Le profil de sécurité TLS définit la version minimale de TLS et les algorithmes de chiffrement TLS pour les connexions TLS des contrôleurs d'entrée.

Les chiffres et la version TLS minimale du profil de sécurité TLS configuré sont indiqués dans la ressource personnalisée (CR) IngressController sous Status.Tls Profile et dans le profil de sécurité TLS configuré sous Spec.Tls Security Profile. Pour le profil de sécurité TLS Custom, les algorithmes de chiffrement spécifiques et la version TLS minimale sont répertoriés sous les deux paramètres.

Note

L'image du contrôleur d'entrée HAProxy prend en charge TLS 1.3 et le profil Modern.

L'opérateur d'entrée convertit également le TLS 1.0 d'un profil Old ou Custom en 1.1.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  1. Modifiez le CR IngressController dans le projet openshift-ingress-operator pour configurer le profil de sécurité TLS : 

    $ oc edit IngressController default -n openshift-ingress-operator

  2. Ajouter le champ spec.tlsSecurityProfile:

    Exemple de CR IngressController pour un profil Custom 

    apiVersion: operator.openshift.io/v1
kind: IngressController
 ...
spec:
  tlsSecurityProfile:
    type: Custom 1
    custom: 2
      ciphers: 3
      - ECDHE-ECDSA-CHACHA20-POLY1305
      - ECDHE-RSA-CHACHA20-POLY1305
      - ECDHE-RSA-AES128-GCM-SHA256
      - ECDHE-ECDSA-AES128-GCM-SHA256
      minTLSVersion: VersionTLS11
 ...

    1
    Spécifiez le type de profil de sécurité TLS (Old, Intermediate, ou Custom). La valeur par défaut est Intermediate.
    2
    Spécifiez le champ approprié pour le type sélectionné :
    • old: {}
    • intermediate: {}
    • custom:
    3
    Pour le type custom, spécifiez une liste de chiffrements TLS et la version TLS minimale acceptée.
  3. Enregistrez le fichier pour appliquer les modifications.

Vérification

  • Vérifiez que le profil est défini dans le CR IngressController: 

    $ oc describe IngressController default -n openshift-ingress-operator

    Exemple de sortie

    Name:         default
Namespace:    openshift-ingress-operator
Labels:       <none>
Annotations:  <none>
API Version:  operator.openshift.io/v1
Kind:         IngressController
 ...
Spec:
 ...
  Tls Security Profile:
    Custom:
      Ciphers:
        ECDHE-ECDSA-CHACHA20-POLY1305
        ECDHE-RSA-CHACHA20-POLY1305
        ECDHE-RSA-AES128-GCM-SHA256
        ECDHE-ECDSA-AES128-GCM-SHA256
      Min TLS Version:  VersionTLS11
    Type:               Custom
 ...

7.3.1.3. Configuration de l'authentification mutuelle TLS

Vous pouvez configurer le contrôleur d'entrée pour activer l'authentification mutuelle TLS (mTLS) en définissant une valeur spec.clientTLS. La valeur clientTLS configure le contrôleur d'entrée pour qu'il vérifie les certificats des clients. Cette configuration comprend la définition d'une valeur clientCA, qui est une référence à une carte de configuration. La carte de configuration contient le paquet de certificats CA codé PEM utilisé pour vérifier le certificat d'un client. En option, vous pouvez configurer une liste de filtres de sujet de certificat.

Si la valeur clientCA indique un point de distribution de liste de révocation de certificats (CRL) X509v3, l'opérateur d'entrée télécharge la CRL et configure le contrôleur d'entrée pour qu'il en prenne acte. Les demandes qui ne fournissent pas de certificats valides sont rejetées.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  1. Créer une carte de configuration dans l'espace de noms openshift-config: 

    $ oc create configmap router-ca-certs-default --from-file=ca-bundle.pem=client-ca.crt -n openshift-config
    Note

    La clé de données de la carte de configuration doit être ca-bundle.pem, et la valeur des données doit être un certificat d'autorité de certification au format PEM.

  2. Modifiez la ressource IngressController dans le projet openshift-ingress-operator: 

    $ oc edit IngressController default -n openshift-ingress-operator

  3. Ajoutez le champ spec.clientTLS et ses sous-champs pour configurer le TLS mutuel :

    Exemple de CR IngressController pour un profil clientTLS qui spécifie des modèles de filtrage

      apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    clientTLS:
      clientCertificatePolicy: Required
      clientCA:
        name: router-ca-certs-default
      allowedSubjectPatterns:
      - "^/CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift$"