Chapitre 9. Configuration des itinéraires

9.1.1. Création d’une route HTTP
Copier lien

Créez un itinéraire pour héberger votre application à une URL publique. L’itinéraire peut être sécurisé ou non sécurisé, en fonction de la configuration de sécurité réseau de votre application. La route HTTP est une route non sécurisée qui utilise le protocole de routage HTTP de base et expose un service sur un port d’application non sécurisé.

La procédure suivante décrit comment créer une route HTTP simple vers une application Web, en utilisant l’application hello-openshift comme exemple.

Conditions préalables

Installation de l’OpenShift CLI (oc).
En tant qu’administrateur, vous êtes connecté.
Il existe une application web qui expose un port et un point de terminaison TCP à l’écoute du trafic sur le port.

Procédure

Créez un projet appelé hello-openshift en exécutant la commande suivante:
```
oc new-project hello-openshift
```
```
$ oc new-project hello-openshift
```
Copy to Clipboard Toggle word wrap

Créez un pod dans le projet en exécutant la commande suivante:

oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json

$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json

Copy to Clipboard

Toggle word wrap

Créez un service appelé hello-openshift en exécutant la commande suivante:
```
oc expose pod/hello-openshift
```
```
$ oc expose pod/hello-openshift
```
Copy to Clipboard Toggle word wrap
Créez une route non sécurisée vers l’application hello-openshift en exécutant la commande suivante:
```
oc expose svc hello-openshift
```
```
$ oc expose svc hello-openshift
```
Copy to Clipboard Toggle word wrap

La vérification

Afin de vérifier que la ressource d’itinéraire que vous avez créée exécute la commande suivante:
```
oc get routes -o yaml <name of resource>
```
```
$ oc get routes -o yaml <name of resource> 
```
1
Copy to Clipboard Toggle word wrap
1
Dans cet exemple, l’itinéraire est nommé hello-openshift.

Exemple de définition YAML de l’itinéraire non sécurisé créé

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: hello-openshift
spec:
  host: www.example.com 
  port:
    targetPort: 8080 
  to:
    kind: Service
    name: hello-openshift

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: hello-openshift
spec:
  host: www.example.com

1


  port:
    targetPort: 8080

2


  to:
    kind: Service
    name: hello-openshift

Copy to Clipboard

Toggle word wrap

1

Le champ hôte est un enregistrement DNS alias qui pointe vers le service. Ce champ peut être n’importe quel nom DNS valide, tel que www.example.com. Le nom DNS doit suivre les conventions de sous-domaine DNS952. Lorsqu’il n’est pas spécifié, un nom d’itinéraire est automatiquement généré.

2

Le champ TargetPort est le port cible sur les pods qui est sélectionné par le service auquel cette route pointe.

Note

Afin d’afficher votre domaine d’entrée par défaut, exécutez la commande suivante:

oc get ingresses.config/cluster -o jsonpath={.spec.domain}

$ oc get ingresses.config/cluster -o jsonpath={.spec.domain}

Copy to Clipboard

Toggle word wrap

9.1.2. Configuration des délais d’itinéraire
Copier lien

Il est possible de configurer les délais par défaut pour un itinéraire existant lorsque vous avez des services qui ont besoin d’un délai d’attente réduit, ce qui est nécessaire aux fins de la disponibilité de niveau de service (SLA), ou d’un délai d’attente élevé, pour les cas où le retard est lent.

Conditions préalables

Il vous faut un contrôleur Ingress déployé sur un cluster en cours d’exécution.

Procédure

En utilisant la commande oc annotate, ajoutez le timeout à l’itinéraire:
```
oc annotate route <route_name> \
    --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>
```
```
$ oc annotate route <route_name> \
    --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit> 
```
1
Copy to Clipboard Toggle word wrap
1
Les unités de temps prises en charge sont les microsecondes (nous), les millisecondes (ms), les secondes (s), les minutes (m), les heures (h) ou les jours (d).
L’exemple suivant définit un délai de deux secondes sur un itinéraire nommé myroute:
```
oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
```
```
$ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
```
Copy to Clipboard Toggle word wrap

9.1.3. HTTP Strict Transport Security
Copier lien

La stratégie HTTP Strict Transport Security (HSTS) est une amélioration de la sécurité, qui signale au client du navigateur que seul le trafic HTTPS est autorisé sur l’hôte de route. HSTS optimise également le trafic Web en signalant le transport HTTPS, sans utiliser de redirections HTTP. HSTS est utile pour accélérer les interactions avec les sites Web.

Lorsque la politique HSTS est appliquée, HSTS ajoute un en-tête Strict Transport Security aux réponses HTTP et HTTPS du site. Il est possible d’utiliser la valeur insecureEdgeTerminationPolicy dans un itinéraire pour rediriger HTTP vers HTTPS. Lorsque HSTS est appliqué, le client modifie toutes les requêtes de l’URL HTTP en HTTPS avant l’envoi de la requête, éliminant ainsi la nécessité d’une redirection.

Les administrateurs de clusters peuvent configurer HSTS pour faire ce qui suit:

Activer le HSTS par route
Désactiver le HSTS par route
Appliquer HSTS par domaine, pour un ensemble de domaines, ou utiliser des étiquettes d’espace de noms en combinaison avec des domaines

Important

HSTS ne fonctionne qu’avec des routes sécurisées, soit terminales soit recryptées. La configuration est inefficace sur les routes HTTP ou passthrough.

9.1.3.1. Activer HTTP Strict Transport Security par route
Copier lien

HTTP strict de sécurité de transport (HSTS) est implémenté dans le modèle HAProxy et appliqué à bord et recrypter les routes qui ont l’annotation haproxy.router.openshift.io/hsts_header.

Conditions préalables

Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur pour le projet.
Installation de l’OpenShift CLI (oc).

Procédure

Afin d’activer HSTS sur une route, ajoutez la valeur haproxy.router.openshift.io/hsts_header à la route terminale ou recryptée. Il est possible d’utiliser l’outil oc annotate pour le faire en exécutant la commande suivante. Afin d’exécuter correctement la commande, assurez-vous que le point-virgule (;) dans l’annotation de route haproxy.router.openshift.io/hsts_header est également entouré de guillemets doubles ("").
Exemple de commande annotée qui fixe l’âge maximum à 31536000 ms (environ 8,5 heures)
```
oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header=max-age=31536000;\
includeSubDomains;preload"
```
```
$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header=max-age=31536000;\
includeSubDomains;preload"
```
Copy to Clipboard Toggle word wrap
Exemple d’itinéraire configuré avec une annotation
```
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload   
# ...
spec:
  host: def.abc.com
  tls:
    termination: "reencrypt"
    ...
  wildcardPolicy: "Subdomain"
# ...
```
```
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload 
```
1
```
 
```
2
```
 
```
3
```
# ...
spec:
  host: def.abc.com
  tls:
    termination: "reencrypt"
    ...
  wildcardPolicy: "Subdomain"
# ...
```
Copy to Clipboard Toggle word wrap
1
C’est nécessaire. l’âge maximal mesure la durée, en secondes, que la politique sur le TVH est en vigueur. Lorsqu’il est défini à 0, il annule la politique.
2
En option. Lorsqu’il est inclus, includeSubDomains indique au client que tous les sous-domaines de l’hôte doivent avoir la même politique HSTS que l’hôte.
3
En option. Lorsque l’âge maximum est supérieur à 0, vous pouvez ajouter la précharge dans haproxy.router.openshift.io/hsts_header pour permettre aux services externes d’inclure ce site dans leurs listes de préchargement HSTS. À titre d’exemple, des sites tels que Google peuvent construire une liste de sites qui ont un préchargement défini. Les navigateurs peuvent ensuite utiliser ces listes pour déterminer les sites avec lesquels ils peuvent communiquer via HTTPS, avant même qu’ils n’aient interagi avec le site. En l’absence de préchargement, les navigateurs doivent avoir interagi avec le site via HTTPS, au moins une fois, pour obtenir l’en-tête.

9.1.3.2. Désactivation de HTTP Strict Transport Security par route
Copier lien

Afin de désactiver HTTP strict de sécurité de transport (HSTS) par route, vous pouvez définir la valeur d’âge maximum dans l’annotation de route à 0.

Conditions préalables

Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur pour le projet.
Installation de l’OpenShift CLI (oc).

Procédure

Afin de désactiver le HSTS, définissez la valeur d’âge max dans l’annotation de route à 0, en entrant la commande suivante:

oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"

$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"

Copy to Clipboard

Toggle word wrap

Astuce

Alternativement, vous pouvez appliquer le YAML suivant pour créer la carte de configuration:

Exemple de désactivation du TVH par route

metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=0

metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=0

Copy to Clipboard

Toggle word wrap

Afin de désactiver les HSTS pour chaque route dans un espace de noms, entrez la commande suivante:

oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"

$ oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"

Copy to Clipboard

Toggle word wrap

La vérification

Afin d’interroger l’annotation pour tous les itinéraires, entrez la commande suivante:

oc get route  --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'

$ oc get route  --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Name: routename HSTS: max-age=0

Name: routename HSTS: max-age=0

Copy to Clipboard

Toggle word wrap

9.1.4. En utilisant des cookies pour garder l’état de route
Copier lien

Le service OpenShift Red Hat sur AWS fournit des sessions collantes, ce qui permet un trafic d’application étatique en s’assurant que tous les trafics atteignent le même point de terminaison. Cependant, si le point d’extrémité se termine, que ce soit par redémarrage, mise à l’échelle, ou un changement de configuration, cet état d’état peut disparaître.

Le service OpenShift de Red Hat sur AWS peut utiliser des cookies pour configurer la persistance des sessions. Le contrôleur d’entrée sélectionne un point de terminaison pour traiter les demandes de l’utilisateur et crée un cookie pour la session. Le cookie est réintégré dans la réponse à la demande et l’utilisateur renvoie le cookie avec la demande suivante dans la session. Le cookie indique au contrôleur d’entrée quel point de terminaison traite la session, s’assurant que les demandes du client utilisent le cookie afin qu’ils soient acheminés vers le même pod.

Note

Les cookies ne peuvent pas être définis sur les routes de passage, car le trafic HTTP ne peut pas être vu. Au lieu de cela, un nombre est calculé en fonction de l’adresse IP source, qui détermine le backend.

En cas de changement de backend, le trafic peut être dirigé vers le mauvais serveur, ce qui le rend moins collant. Lorsque vous utilisez un balanceur de charge, qui cache l’IP source, le même nombre est défini pour toutes les connexions et le trafic est envoyé au même pod.

9.1.4.1. Annotation d’un itinéraire avec un cookie
Copier lien

Il est possible de définir un nom de cookie pour écraser le nom par défaut, généré automatiquement pour l’itinéraire. Cela permet à l’application recevant du trafic d’itinéraire de connaître le nom du cookie. La suppression du cookie peut forcer la prochaine demande à re-choisir un point de terminaison. Le résultat est que si un serveur est surchargé, ce serveur essaie de supprimer les requêtes du client et de les redistribuer.

Procédure

Annoter l’itinéraire avec le nom de cookie spécifié:
```
oc annotate route <route_name> router.openshift.io/cookie_name="<cookie_name>"
```
```
$ oc annotate route <route_name> router.openshift.io/cookie_name="<cookie_name>"
```
Copy to Clipboard Toggle word wrap
là où:
<route_nom>
Indique le nom de l’itinéraire.
<cookie_name>
Indique le nom du cookie.
A titre d’exemple, annoter l’itinéraire my_route avec le nom de cookie my_cookie:
```
oc annotate route my_route router.openshift.io/cookie_name="my_cookie"
```
```
$ oc annotate route my_route router.openshift.io/cookie_name="my_cookie"
```
Copy to Clipboard Toggle word wrap
Capturez le nom d’hôte de l’itinéraire dans une variable:
```
ROUTE_NAME=$(oc get route <route_name> -o jsonpath='{.spec.host}')
```
```
$ ROUTE_NAME=$(oc get route <route_name> -o jsonpath='{.spec.host}')
```
Copy to Clipboard Toggle word wrap
là où:
<route_nom>
Indique le nom de l’itinéraire.
Enregistrez le cookie, puis accédez à l’itinéraire:
```
curl $ROUTE_NAME -k -c /tmp/cookie_jar
```
```
$ curl $ROUTE_NAME -k -c /tmp/cookie_jar
```
Copy to Clipboard Toggle word wrap
Lorsque vous vous connectez à l’itinéraire, utilisez le cookie enregistré par la commande précédente:
```
curl $ROUTE_NAME -k -b /tmp/cookie_jar
```
```
$ curl $ROUTE_NAME -k -b /tmp/cookie_jar
```
Copy to Clipboard Toggle word wrap

9.1.5. Itinéraires basés sur le chemin
Copier lien

Les routes basées sur le chemin spécifient un composant de chemin qui peut être comparé à une URL, ce qui nécessite que le trafic pour l’itinéraire soit basé sur HTTP. Ainsi, plusieurs itinéraires peuvent être desservis en utilisant le même nom d’hôte, chacun avec un chemin différent. Les routeurs doivent correspondre à des itinéraires basés sur le chemin le plus spécifique au moins.

Le tableau suivant présente des exemples d’itinéraires et leur accessibilité:

Expand

Tableau 9.1. Disponibilité de l’itinéraire
Itinéraire	Lorsque comparé à	Accessible
www.example.com/test	www.example.com/test	♪ oui ♪
www.example.com/test	www.example.com	C) Non
www.example.com/test et www.example.com	www.example.com/test	♪ oui ♪
www.example.com/test et www.example.com	www.example.com	♪ oui ♪
www.example.com	www.example.com/text	(Matched par l’hôte, pas l’itinéraire)
www.example.com	www.example.com	♪ oui ♪

Itinéraire non sécurisé avec un chemin

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-unsecured
spec:
  host: www.example.com
  path: "/test" 
  to:
    kind: Service
    name: service-name

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-unsecured
spec:
  host: www.example.com
  path: "/test"

1


  to:
    kind: Service
    name: service-name

Copy to Clipboard

Toggle word wrap

1: Le chemin est le seul attribut ajouté pour une route basée sur le chemin.

Note

Le routage basé sur le chemin n’est pas disponible lors de l’utilisation de TLS passthrough, car le routeur ne met pas fin à TLS dans ce cas et ne peut pas lire le contenu de la demande.

9.1.6. Configuration d’en-tête HTTP
Copier lien

Le service OpenShift Red Hat sur AWS fournit différentes méthodes pour travailler avec les en-têtes HTTP. Lorsque vous configurez ou supprimez des en-têtes, vous pouvez utiliser des champs spécifiques dans le contrôleur d’Ingress ou un itinéraire individuel pour modifier les en-têtes de requête et de réponse. Il est également possible de définir certains en-têtes en utilisant des annotations d’itinéraire. Les différentes façons de configurer les en-têtes peuvent présenter des défis lorsque vous travaillez ensemble.

Note

Il est possible de définir ou de supprimer uniquement des en-têtes au sein d’un IngressController ou Route CR, vous ne pouvez pas les ajouter. Lorsqu’un en-tête HTTP est défini avec une valeur, cette valeur doit être complète et ne pas nécessiter d’ajouter à l’avenir. Dans les situations où il est logique d’ajouter un en-tête, comme l’en-tête X-Forwarded-Forwarded, utilisez le champ spec.httpHeaders.forwardedHeaderPolicy, au lieu de spec.httpHeaders.actions.

9.1.6.1. Ordre de préséance
Copier lien

Lorsque le même en-tête HTTP est modifié à la fois dans le contrôleur Ingress et dans un itinéraire, HAProxy priorise les actions de certaines manières selon qu’il s’agit d’une requête ou d’un en-tête de réponse.

Dans le cas des en-têtes de réponse HTTP, les actions spécifiées dans le contrôleur Ingress sont exécutées après les actions spécifiées dans un itinéraire. Cela signifie que les actions spécifiées dans le Contrôleur Ingress ont préséance.
Dans le cas des en-têtes de requête HTTP, les actions spécifiées dans une route sont exécutées après les actions spécifiées dans le contrôleur Ingress. Cela signifie que les actions spécifiées dans l’itinéraire ont préséance.

À titre d’exemple, un administrateur de cluster définit l’en-tête de réponse X-Frame-Options avec la valeur DENY dans le contrôleur Ingress en utilisant la configuration suivante:

Exemple IngressController spec

apiVersion: operator.openshift.io/v1
kind: IngressController
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: DENY

apiVersion: operator.openshift.io/v1
kind: IngressController
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: DENY

Copy to Clipboard

Toggle word wrap

Le propriétaire de route définit le même en-tête de réponse que l’administrateur du cluster défini dans le contrôleur Ingress, mais avec la valeur SAMEORIGIN en utilisant la configuration suivante:

Exemple de route Spécification

apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: SAMEORIGIN

apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: SAMEORIGIN

Copy to Clipboard

Toggle word wrap

Lorsque les spécifications IngressController et Route configurent l’en-tête de réponse X-Frame-Options, alors la valeur définie pour cet en-tête au niveau global dans le contrôleur Ingress a préséance, même si un itinéraire spécifique permet des cadres. Dans le cas d’un en-tête de requête, la valeur spec de Route remplace la valeur spec d’IngressController.

Cette priorisation se produit parce que le fichier haproxy.config utilise la logique suivante, où le contrôleur Ingress est considéré comme l’extrémité avant et les itinéraires individuels sont considérés comme l’arrière-plan. La valeur d’en-tête DENY appliquée aux configurations d’extrémité avant remplace le même en-tête avec la valeur SAMEORIGIN définie dans l’arrière:

frontend public
  http-response set-header X-Frame-Options 'DENY'

frontend fe_sni
  http-response set-header X-Frame-Options 'DENY'

frontend fe_no_sni
  http-response set-header X-Frame-Options 'DENY'

backend be_secure:openshift-monitoring:alertmanager-main
  http-response set-header X-Frame-Options 'SAMEORIGIN'

frontend public
  http-response set-header X-Frame-Options 'DENY'

frontend fe_sni
  http-response set-header X-Frame-Options 'DENY'

frontend fe_no_sni
  http-response set-header X-Frame-Options 'DENY'

backend be_secure:openshift-monitoring:alertmanager-main
  http-response set-header X-Frame-Options 'SAMEORIGIN'

Copy to Clipboard

Toggle word wrap

En outre, toutes les actions définies dans le contrôleur d’Ingress ou dans une route remplacent les valeurs définies à l’aide d’annotations d’itinéraire.

9.1.6.2. En-têtes de cas spéciaux
Copier lien

Les en-têtes suivants sont soit empêchés entièrement d’être réglés ou supprimés, soit autorisés dans des circonstances spécifiques:

Expand

Tableau 9.2. Configuration d’en-tête de cas spécial
Le nom de l’en-tête	Configurable en utilisant IngressController spec	Configurable à l’aide de Route spec	La raison de l’exclusion	Configurable en utilisant une autre méthode
`le proxy`	C) Non	C) Non	L’en-tête de requête HTTP proxy peut être utilisé pour exploiter les applications CGI vulnérables en injectant la valeur d’en-tête dans la variable d’environnement HTTP_PROXY. L’en-tête de requête HTTP proxy est également non standard et sujet à une erreur lors de la configuration.	C) Non
`hôte`	C) Non	♪ oui ♪	Lorsque l’en-tête de requête HTTP hôte est défini à l’aide de l’IngressController CR, HAProxy peut échouer lors de la recherche de la bonne route.	C) Non
`stricte-transport-sécurité`	C) Non	C) Non	L’en-tête de réponse HTTP strict-transport-sécurité est déjà géré à l’aide d’annotations de route et n’a pas besoin d’une implémentation séparée.	L’annotation de route haproxy.router.openshift.io/hsts_header
cookie et set-cookie	C) Non	C) Non	Les cookies que HAProxy définit sont utilisés pour le suivi de session pour cartographier les connexions client à des serveurs back-end particuliers. La mise en place de ces en-têtes pourrait interférer avec l’affinité de la session de HAProxy et restreindre la propriété d’un cookie par HAProxy.	C’est oui: l’annotation de l’itinéraire haproxy.router.openshift.io/désable_cookie l’annotation de route haproxy.router.openshift.io/cookie_name

9.1.7. Définir ou supprimer les en-têtes de requête et de réponse HTTP dans un itinéraire
Copier lien

Il est possible de définir ou de supprimer certains en-têtes de requête et de réponse HTTP à des fins de conformité ou pour d’autres raisons. Ces en-têtes peuvent être définis ou supprimés soit pour tous les itinéraires desservis par un contrôleur d’Ingress, soit pour des itinéraires spécifiques.

À titre d’exemple, vous voudrez peut-être activer une application Web à servir du contenu dans d’autres endroits pour des itinéraires spécifiques si ce contenu est écrit en plusieurs langues, même s’il existe un emplacement global par défaut spécifié par le contrôleur Ingress desservant les routes.

La procédure suivante crée un itinéraire qui définit l’en-tête de requête HTTP Content-Location de sorte que l’URL associée à l’application, https://app.example.com, dirige vers l’emplacement https://app.example.com/lang/en-us. Diriger le trafic d’application vers cet emplacement signifie que toute personne utilisant cette route spécifique accède au contenu Web écrit en anglais américain.

Conditions préalables

L’OpenShift CLI (oc) a été installé.
En tant qu’administrateur de projet, vous êtes connecté à un service Red Hat OpenShift sur AWS cluster.
Il existe une application Web qui expose un port et un point de terminaison HTTP ou TLS à l’écoute du trafic sur le port.

Procédure

Créez une définition d’itinéraire et enregistrez-la dans un fichier appelé app-example-route.yaml:
Définition YAML de l’itinéraire créé avec les directives d’en-tête HTTP
```
apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  host: app.example.com
  tls:
    termination: edge
  to:
    kind: Service
    name: app-example
  httpHeaders:
    actions: 
      response: 
      - name: Content-Location 
        action:
          type: Set 
          set:
            value: /lang/en-us 
```
```
apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  host: app.example.com
  tls:
    termination: edge
  to:
    kind: Service
    name: app-example
  httpHeaders:
    actions: 
```
1
```
      response: 
```
2
```
      - name: Content-Location 
```
3
```
        action:
          type: Set 
```
4
```
          set:
            value: /lang/en-us 
```
5
Copy to Clipboard Toggle word wrap
1
La liste des actions que vous souhaitez effectuer sur les en-têtes HTTP.
2
Le type d’en-tête que vous voulez changer. Dans ce cas, un en-tête de réponse.
3
Le nom de l’en-tête que vous voulez changer. Dans le cas d’une liste d’en-têtes disponibles que vous pouvez définir ou supprimer, voir la configuration d’en-tête HTTP.
4
Le type d’action en cours sur l’en-tête. Ce champ peut avoir la valeur Set ou Supprimer.
5
Lorsque vous définissez des en-têtes HTTP, vous devez fournir une valeur. La valeur peut être une chaîne à partir d’une liste de directives disponibles pour cet en-tête, par exemple DENY, ou il peut s’agir d’une valeur dynamique qui sera interprétée à l’aide de la syntaxe de valeur dynamique de HAProxy. Dans ce cas, la valeur est définie à l’emplacement relatif du contenu.
Créez un itinéraire vers votre application Web existante en utilisant la définition de route nouvellement créée:
```
oc -n app-example create -f app-example-route.yaml
```
```
$ oc -n app-example create -f app-example-route.yaml
```
Copy to Clipboard Toggle word wrap

Dans le cas des en-têtes de requête HTTP, les actions spécifiées dans les définitions de route sont exécutées après toutes les actions effectuées sur les en-têtes de requête HTTP dans le contrôleur Ingress. Cela signifie que toutes les valeurs définies pour ces en-têtes de requête dans un itinéraire auront préséance sur celles définies dans le contrôleur Ingress. Consultez la configuration de l’en-tête HTTP pour plus d’informations sur l’ordre de traitement des en-têtes HTTP.

9.1.8. Annotations spécifiques à la route
Copier lien

Le contrôleur Ingress peut définir les options par défaut pour tous les itinéraires qu’il expose. L’itinéraire individuel peut remplacer certaines de ces valeurs par défaut en fournissant des configurations spécifiques dans ses annotations. Le Red Hat ne prend pas en charge l’ajout d’une annotation d’itinéraire à une route gérée par l’opérateur.

Important

Afin de créer une liste d’autorisation avec plusieurs sources IP ou sous-réseaux, utilisez une liste délimitée dans l’espace. Dans tout autre type de délimiteur, la liste est ignorée sans message d’avertissement ou d’erreur.

Expand

Tableau 9.3. Annotations de route
La variable	Description	La variable d’environnement utilisée par défaut
`HAProxy.router.openshift.io/balance`	Définit l’algorithme d’équilibrage de charge. Les options disponibles sont aléatoires, source, rondrobine et leastconn. La valeur par défaut est source pour les routes de passage TLS. Dans tous les autres itinéraires, la valeur par défaut est aléatoire.	Le ROUTER_TCP_BALANCE_SCHEME pour les routes de passage. Dans le cas contraire, utilisez ROUTER_LOAD_BALANCE_ALGORITHM.
`HAProxy.router.openshift.io/désable_cookies`	Désactive l’utilisation de cookies pour suivre les connexions connexes. Lorsqu’il est défini sur 'vrai' ou 'TRUE', l’algorithme d’équilibre est utilisé pour choisir quel back-end sert les connexions pour chaque requête HTTP entrante.
`router.openshift.io/cookie_name`	Indique un cookie optionnel à utiliser pour cet itinéraire. Le nom doit être composé de toute combinaison de lettres majuscules et minuscules, chiffres, "_" et "-". La valeur par défaut est le nom de clé interne haché pour l’itinéraire.
`HAProxy.router.openshift.io/pod-concurrent-connections`	Définit le nombre maximum de connexions autorisées à une gousse de support à partir d’un routeur. Attention : S’il y a plusieurs pods, chacun peut avoir autant de connexions. « si vous avez plusieurs routeurs, il n’y a pas de coordination entre eux, chacun peut connecter cela plusieurs fois. Lorsqu’il n’est pas défini, ou défini à 0, il n’y a pas de limite.
`HAProxy.router.openshift.io/rate-limit-connections`	La définition de 'vrai' ou 'TRUE' permet de limiter le taux de fonctionnalité qui est implémentée par le biais de stick-tables sur le backend spécifique par route. L’utilisation de cette annotation fournit une protection de base contre les attaques par déni de service.
`HAProxy.router.openshift.io/rate-limit-connections.concurrent-tcp`	Limite le nombre de connexions TCP simultanées effectuées via la même adresse IP source. Il accepte une valeur numérique. L’utilisation de cette annotation fournit une protection de base contre les attaques par déni de service.
`HAProxy.router.openshift.io/rate-limit-connections.rate-http`	Limite le taux auquel un client avec la même adresse IP source peut faire des requêtes HTTP. Il accepte une valeur numérique. L’utilisation de cette annotation fournit une protection de base contre les attaques par déni de service.
`HAProxy.router.openshift.io/rate-limit-connections.rate-tcp`	Limite le taux auquel un client avec la même adresse IP source peut effectuer des connexions TCP. Il accepte une valeur numérique. L’utilisation de cette annotation fournit une protection de base contre les attaques par déni de service.
`HAProxy.router.openshift.io/timeout`	Définit un temps d’attente côté serveur pour l’itinéraire. (Unités temporelles)	`AJOUTER AU PANIER ROUTER_DEFAULT_SERVER_TIMEOUT`
`HAProxy.router.openshift.io/timeout-tunnel`	Ce délai s’applique à une connexion tunnel, par exemple, WebSocket sur des routes de texte clair, bord, recryptage ou passthrough. Avec le texte clair, le bord ou le recryptage des types d’itinéraires, cette annotation est appliquée en tant que tunnel d’expiration avec la valeur de timeout existante. Dans le cas des types d’itinéraires de passage, l’annotation prime sur toute valeur de temps d’attente existante.	`AJOUTER AU PANIER ROUTER_DEFAULT_TUNNEL_TIMEOUT`
`ingresses.config/cluster ingress.operator.openshift.io/hard-stop-after`	Il est possible de définir soit un IngressController, soit la configuration d’entrée. Cette annotation redéploie le routeur et configure le proxy HA pour émettre l’option haproxy hard-stop-après global, qui définit le temps maximum autorisé pour effectuer un arrêt souple propre.	`AJOUTER AU PANIER ROUTER_HARD_STOP_AFTER`
`router.openshift.io/haproxy.health.check.interval`	Définit l’intervalle pour les contrôles de santé back-end. (Unités temporelles)	`ENTREPRISE_BACKEND_CHECK_INTERVAL`
`HAProxy.router.openshift.io/ip_allowlist`	Définit une liste d’autorisations pour l’itinéraire. La liste d’autorisation est une liste séparée d’adresses IP et de gammes CIDR pour les adresses source approuvées. Les demandes d’adresses IP qui ne figurent pas dans la liste d’autorisation sont supprimées. Le nombre maximum d’adresses IP et de plages CIDR directement visibles dans le fichier haproxy.config est de 61. [1]
`HAProxy.router.openshift.io/hsts_header`	Définit un en-tête Strict-Transport-Security pour la route terminée ou recryptée.
`HAProxy.router.openshift.io/rewrite-target`	Définit le chemin de réécriture de la requête sur le backend.
`accueil > Router.openshift.io/cookie-same-site`	Définit une valeur pour restreindre les cookies. Les valeurs sont: Lax: le navigateur n’envoie pas de cookies sur les requêtes croisées, mais envoie des cookies lorsque les utilisateurs naviguent sur le site d’origine à partir d’un site externe. Il s’agit du comportement du navigateur par défaut lorsque la valeur SameSite n’est pas spécifiée. Strict : le navigateur n’envoie des cookies que pour les demandes du même site. Aucun : le navigateur envoie des cookies à la fois pour les demandes intersites et les demandes de même site. Cette valeur s’applique uniquement aux itinéraires recryptés et bordés. Consultez la documentation sur les cookies SameSite pour plus d’informations.
`HAProxy.router.openshift.io/set-forwarded-headers`	Définit la politique de gestion des en-têtes Forwarded et X-Forwarded-Forwarded par route. Les valeurs sont: ajouter: ajoute l’en-tête, en préservant tout en-tête existant. C’est la valeur par défaut. le remplacement : définit l’en-tête, en supprimant tout en en-tête existant. jamais : ne règlez jamais l’en-tête, mais préservent les en-têtes existants. if-none: définit l’en-tête s’il n’est pas déjà réglé.	`LES ROUTER_SET_FORWARDED_HEADERS`

Lorsque le nombre d’adresses IP et de gammes CIDR dans une liste d’autorisation dépasse 61, ils sont écrits dans un fichier séparé qui est ensuite référencé à partir de haproxy.config. Ce fichier est stocké dans le dossier var/lib/haproxy/router/allowlists.
Note
Afin de s’assurer que les adresses sont écrites à la liste d’autorisation, vérifiez que la liste complète des plages CIDR est répertoriée dans le fichier de configuration Ingress Controller. La limite de taille de l’objet etcd limite la taille d’une annotation d’itinéraire. De ce fait, il crée un seuil pour le nombre maximum d’adresses IP et de plages CIDR que vous pouvez inclure dans une liste d’autorisations.

Note

Les variables d’environnement ne peuvent pas être modifiées.

Les variables de timeout du routeur

Les unités de temps sont représentées par un nombre suivi par l’unité: nous *(microsecondes), ms (millisecondes, par défaut), s (secondes), m (minutes), h *(heures), d (jours).

L’expression régulière est: [1-9][0-9]*(us\|ms\|s\|h\|d).

Expand

La variable	Défaut par défaut	Description
`ENTREPRISE_BACKEND_CHECK_INTERVAL`	`5000Ms`	Durée entre les contrôles de vivacité ultérieurs sur les extrémités arrière.
`CLIENT_FIN_TIMEOUT`	`1s`	Contrôle la période d’attente TCP FIN pour le client qui se connecte à l’itinéraire. Lorsque le FIN envoyé pour fermer la connexion ne répond pas dans le délai imparti, HAProxy ferme la connexion. Ceci est inoffensif s’il est défini à une valeur faible et utilise moins de ressources sur le routeur.
`AJOUTER AU PANIER ROUTER_DEFAULT_CLIENT_TIMEOUT`	`30s`	Durée du temps qu’un client doit reconnaître ou envoyer des données.
`AJOUTER AU PANIER ROUTER_DEFAULT_CONNECT_TIMEOUT`	`5s`	Le temps de connexion maximum.
`DEFAULT_SERVER_FIN_TIMEOUT`	`1s`	Contrôle le temps d’attente TCP FIN du routeur jusqu’au pod qui soutient l’itinéraire.
`AJOUTER AU PANIER ROUTER_DEFAULT_SERVER_TIMEOUT`	`30s`	Durée du temps qu’un serveur doit reconnaître ou envoyer des données.
`AJOUTER AU PANIER ROUTER_DEFAULT_TUNNEL_TIMEOUT`	`1h`	Durée pour que les connexions TCP ou WebSocket restent ouvertes. Cette période d’expiration se réinitialise chaque fois que HAProxy se recharge.
`AJOUTER AU PANIER ROUTER_SLOWLORIS_HTTP_KEEPALIVE`	`300s`	Définissez le temps maximum pour attendre l’apparition d’une nouvelle requête HTTP. Lorsque cela est défini trop bas, il peut causer des problèmes avec les navigateurs et les applications ne s’attendant pas à une petite valeur de conservation. Certaines valeurs de timeout efficaces peuvent être la somme de certaines variables, plutôt que le délai d’attente prévu spécifique. À titre d’exemple, ROUTER_SLOWLORIS_HTTP_KEEPALIVE ajuste le délai d’attente http-mainep-alive. Il est réglé sur 300s par défaut, mais HAProxy attend également sur tcp-request inspect-delay, qui est réglé sur 5s. Dans ce cas, le délai d’attente global serait de 300s plus 5s.
`AJOUTER AU PANIER ROUTER_SLOWLORIS_TIMEOUT`	`10s`	Durée de la transmission d’une requête HTTP.
`À PROPOS DE RELOAD_INTERVAL`	`5s`	Autorise la fréquence minimale pour le routeur à recharger et accepter de nouveaux changements.
`AJOUTER AU PANIER ROUTER_METRICS_HAPROXY_TIMEOUT`	`5s`	Délai de collecte des métriques HAProxy.

La configuration d’un itinéraire chronométrage personnalisé

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/timeout: 5500ms 
...

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/timeout: 5500ms

1

...

Copy to Clipboard

Toggle word wrap

1: Indique le nouveau délai d’attente avec les unités prises en charge par HAProxy (nous, ms, s, m, h, d). Dans le cas où l’unité n’est pas fournie, ms est la valeur par défaut.

Note

La définition d’une valeur de temps d’attente côté serveur pour les itinéraires de passage trop bas peut causer des connexions WebSocket fréquemment sur cette route.

Itinéraire qui n’autorise qu’une seule adresse IP spécifique

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 192.168.1.10

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 192.168.1.10

Copy to Clipboard

Toggle word wrap

Itinéraire qui permet plusieurs adresses IP

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 192.168.1.10 192.168.1.11 192.168.1.12

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 192.168.1.10 192.168.1.11 192.168.1.12

Copy to Clipboard

Toggle word wrap

Itinéraire permettant un réseau d’adresse IP CIDR

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 192.168.1.0/24

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 192.168.1.0/24

Copy to Clipboard

Toggle word wrap

Itinéraire permettant à la fois une adresse IP et des réseaux CIDR d’adresse IP

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8

Copy to Clipboard

Toggle word wrap

Itinéraire spécifiant une cible de réécriture

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/rewrite-target: / 
...

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/rewrite-target: /

1

...

Copy to Clipboard

Toggle word wrap

1: Définit / comme chemin de réécriture de la requête sur le backend.

La définition de l’annotation de cible haproxy.router.openshift.io/rewrite-target sur une route spécifie que le contrôleur Ingress devrait réécrire les chemins dans les requêtes HTTP en utilisant cette route avant de transmettre les requêtes à l’application backend. La partie du chemin de requête qui correspond au chemin spécifié dans spec.path est remplacée par la cible de réécriture spécifiée dans l’annotation.

Le tableau suivant fournit des exemples du comportement de réécriture de chemin pour diverses combinaisons de spec.path, de chemin de requête et de réécriture de cible.

Expand

Tableau 9.4. exemples de réécriture-cible
Itinéraire.spec.path	Demander le chemin	La réécriture de la cible	Chemin de demande transmis
/foo	/foo	/	/
/foo	/foo/	/	/
/foo	/foo/bar	/	/bar
/foo	/foo/bar/	/	/bar/
/foo	/foo	/bar	/bar
/foo	/foo/	/bar	/bar/
/foo	/foo/bar	/Baz	/Baz/bar
/foo	/foo/bar/	/Baz	/Baz/bar/
/foo/	/foo	/	Le chemin n/a (request path ne correspond pas au chemin d’itinéraire)
/foo/	/foo/	/	/
/foo/	/foo/bar	/	/bar

Certains caractères spéciaux de haproxy.router.openshift.io/rewrite-target nécessitent une manipulation spéciale car ils doivent être échappés correctement. Consultez le tableau suivant pour comprendre comment ces caractères sont traités.

Expand

Tableau 9.5. Gestion spéciale des caractères
Caractère	À utiliser des caractères	Les notes
♪	\#	Evitez # parce qu’il met fin à l’expression de réécriture
%	% ou %%	Évitez les séquences étranges telles que %%%
''	♪	Éviter ' parce qu’il est ignoré

Les autres caractères URL valides peuvent être utilisés sans s’échapper.

9.1.9. Création d’un itinéraire à l’aide du certificat par défaut via un objet Ingress
Copier lien

Lorsque vous créez un objet Ingress sans spécifier une configuration TLS, Red Hat OpenShift Service sur AWS génère un itinéraire non sécurisé. Afin de créer un objet Ingress qui génère une route sécurisée et terminée par bord à l’aide du certificat d’entrée par défaut, vous pouvez spécifier une configuration TLS vide comme suit.

Conditions préalables

Il y a un service que vous voulez exposer.
Accès à l’OpenShift CLI (oc).

Procédure

Créez un fichier YAML pour l’objet Ingress. Dans cet exemple, le fichier est appelé example-ingress.yaml:
Définition YAML d’un objet Ingress
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend
  ...
spec:
  rules:
    ...
  tls:
  - {} 
```
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend
  ...
spec:
  rules:
    ...
  tls:
  - {} 
```
1
Copy to Clipboard Toggle word wrap
1
Employez cette syntaxe exacte pour spécifier TLS sans spécifier un certificat personnalisé.
Créez l’objet Ingress en exécutant la commande suivante:
```
oc create -f example-ingress.yaml
```
```
$ oc create -f example-ingress.yaml
```
Copy to Clipboard Toggle word wrap

La vérification

Assurez-vous que Red Hat OpenShift Service sur AWS a créé la route attendue pour l’objet Ingress en exécutant la commande suivante:

oc get routes -o yaml

$ oc get routes -o yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: v1
items:
- apiVersion: route.openshift.io/v1
  kind: Route
  metadata:
    name: frontend-j9sdd 
    ...
  spec:
  ...
    tls: 
      insecureEdgeTerminationPolicy: Redirect
      termination: edge 
  ...

apiVersion: v1
items:
- apiVersion: route.openshift.io/v1
  kind: Route
  metadata:
    name: frontend-j9sdd

1


    ...
  spec:
  ...
    tls:

2


      insecureEdgeTerminationPolicy: Redirect
      termination: edge

3

...

Copy to Clipboard

Toggle word wrap

1: Le nom de l’itinéraire comprend le nom de l’objet Ingress suivi d’un suffixe aléatoire.
2: Afin d’utiliser le certificat par défaut, l’itinéraire ne doit pas spécifier spec.certificate.
3: L’itinéraire doit spécifier la stratégie de terminaison des bords.

9.1.10. Création d’un itinéraire à l’aide du certificat CA de destination dans l’annotation Ingress
Copier lien

L’annotation route.openshift.io/destination-ca-certificate-secret peut être utilisée sur un objet Ingress pour définir un itinéraire avec un certificat CA de destination personnalisé.

Conditions préalables

Il se peut que vous ayez une paire de certificats / clé dans les fichiers encodés PEM, où le certificat est valide pour l’hôte de route.
Il se peut que vous ayez un certificat CA distinct dans un fichier codé PEM qui complète la chaîne de certificats.
Il faut avoir un certificat CA de destination distinct dans un fichier encodé PEM.
Il faut avoir un service que vous voulez exposer.

Procédure

Créez un secret pour le certificat CA de destination en entrant la commande suivante:

oc create secret generic dest-ca-cert --from-file=tls.crt=<file_path>

$ oc create secret generic dest-ca-cert --from-file=tls.crt=<file_path>

Copy to Clipboard

Toggle word wrap

À titre d’exemple:

oc -n test-ns create secret generic dest-ca-cert --from-file=tls.crt=tls.crt

$ oc -n test-ns create secret generic dest-ca-cert --from-file=tls.crt=tls.crt

Copy to Clipboard

Toggle word wrap

Exemple de sortie

secret/dest-ca-cert created

secret/dest-ca-cert created

Copy to Clipboard

Toggle word wrap

Ajouter la route.openshift.io/destination-ca-certificate-secret aux annotations d’Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend
  annotations:
    route.openshift.io/termination: "reencrypt"
    route.openshift.io/destination-ca-certificate-secret: secret-ca-cert 
...

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend
  annotations:
    route.openshift.io/termination: "reencrypt"
    route.openshift.io/destination-ca-certificate-secret: secret-ca-cert

1

...

Copy to Clipboard

Toggle word wrap

1: L’annotation fait référence à un secret de kubernetes.

Le secret référencé dans cette annotation sera inséré dans la route générée.

Exemple de sortie

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend
  annotations:
    route.openshift.io/termination: reencrypt
    route.openshift.io/destination-ca-certificate-secret: secret-ca-cert
spec:
...
  tls:
    insecureEdgeTerminationPolicy: Redirect
    termination: reencrypt
    destinationCACertificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
...

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend
  annotations:
    route.openshift.io/termination: reencrypt
    route.openshift.io/destination-ca-certificate-secret: secret-ca-cert
spec:
...
  tls:
    insecureEdgeTerminationPolicy: Redirect
    termination: reencrypt
    destinationCACertificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
...

Copy to Clipboard

Toggle word wrap

9.1. Configuration de l’itinéraire
Copier lien

9.1.1. Création d’une route HTTP
Copier lien

9.1.2. Configuration des délais d’itinéraire
Copier lien

9.1.3. HTTP Strict Transport Security
Copier lien

9.1.3.1. Activer HTTP Strict Transport Security par route
Copier lien

9.1.3.2. Désactivation de HTTP Strict Transport Security par route
Copier lien

9.1.4. En utilisant des cookies pour garder l’état de route
Copier lien

9.1.5. Itinéraires basés sur le chemin
Copier lien

9.1.6. Configuration d’en-tête HTTP
Copier lien

9.1.6.1. Ordre de préséance
Copier lien

9.1.6.2. En-têtes de cas spéciaux
Copier lien

9.1.7. Définir ou supprimer les en-têtes de requête et de réponse HTTP dans un itinéraire
Copier lien

9.1.8. Annotations spécifiques à la route
Copier lien

9.1.9. Création d’un itinéraire à l’aide du certificat par défaut via un objet Ingress
Copier lien

9.1.10. Création d’un itinéraire à l’aide du certificat CA de destination dans l’annotation Ingress
Copier lien

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

Chapitre 9. Configuration des itinéraires

9.1. Configuration de l’itinéraireCopier lienLien copié sur presse-papiers!

9.1.1. Création d’une route HTTPCopier lienLien copié sur presse-papiers!

9.1.2. Configuration des délais d’itinéraireCopier lienLien copié sur presse-papiers!

9.1.3. HTTP Strict Transport SecurityCopier lienLien copié sur presse-papiers!

9.1.3.1. Activer HTTP Strict Transport Security par routeCopier lienLien copié sur presse-papiers!

9.1.3.2. Désactivation de HTTP Strict Transport Security par routeCopier lienLien copié sur presse-papiers!

9.1.4. En utilisant des cookies pour garder l’état de routeCopier lienLien copié sur presse-papiers!

9.1.4.1. Annotation d’un itinéraire avec un cookieCopier lienLien copié sur presse-papiers!

9.1.5. Itinéraires basés sur le cheminCopier lienLien copié sur presse-papiers!

9.1.6. Configuration d’en-tête HTTPCopier lienLien copié sur presse-papiers!

9.1.6.1. Ordre de préséanceCopier lienLien copié sur presse-papiers!

9.1.6.2. En-têtes de cas spéciauxCopier lienLien copié sur presse-papiers!

9.1.7. Définir ou supprimer les en-têtes de requête et de réponse HTTP dans un itinéraireCopier lienLien copié sur presse-papiers!

9.1.8. Annotations spécifiques à la routeCopier lienLien copié sur presse-papiers!

9.1.9. Création d’un itinéraire à l’aide du certificat par défaut via un objet IngressCopier lienLien copié sur presse-papiers!

9.1.10. Création d’un itinéraire à l’aide du certificat CA de destination dans l’annotation IngressCopier lienLien copié sur presse-papiers!

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

9.1. Configuration de l’itinéraire
Copier lien

9.1.1. Création d’une route HTTP
Copier lien

9.1.2. Configuration des délais d’itinéraire
Copier lien

9.1.3. HTTP Strict Transport Security
Copier lien

9.1.3.1. Activer HTTP Strict Transport Security par route
Copier lien

9.1.3.2. Désactivation de HTTP Strict Transport Security par route
Copier lien

9.1.4. En utilisant des cookies pour garder l’état de route
Copier lien

9.1.4.1. Annotation d’un itinéraire avec un cookie
Copier lien

9.1.5. Itinéraires basés sur le chemin
Copier lien

9.1.6. Configuration d’en-tête HTTP
Copier lien

9.1.6.1. Ordre de préséance
Copier lien

9.1.6.2. En-têtes de cas spéciaux
Copier lien

9.1.7. Définir ou supprimer les en-têtes de requête et de réponse HTTP dans un itinéraire
Copier lien

9.1.8. Annotations spécifiques à la route
Copier lien

9.1.9. Création d’un itinéraire à l’aide du certificat par défaut via un objet Ingress
Copier lien

9.1.10. Création d’un itinéraire à l’aide du certificat CA de destination dans l’annotation Ingress
Copier lien