Contrôleur d'entrée Citrix ADC

Gestion des certificats TLS dans le Citrix ingress controller

Le Citrix ingress controller offre la possibilité de configurer des certificats TLS pour les serveurs virtuels basés sur SSL Citrix ADC. Le serveur virtuel SSL intercepte le trafic SSL, le déchiffre et le traite avant de l’envoyer aux services liés au serveur virtuel.

Par défaut, le serveur virtuel SSL peut se lier à un certificat par défaut et l’application reçoit le trafic en fonction de la stratégie liée au certificat. Toutefois, vous disposez de l’option SNI (Server Name Indication) pour lier plusieurs certificats à un seul serveur virtuel. Citrix ADC détermine le certificat à présenter au client en fonction du nom de domaine dans la poignée de main TLS.

Le Citrix ingress controller gère les certificats des trois manières suivantes :

Conditions préalables

Pour gérer les certificats TLS à l’aide du Citrix ingress controller, vous devez activer la prise en charge TLS dans Citrix ADC pour l’application et également si vous utilisez des certificats dans votre déploiement Kubernetes, vous devez générer un secret Kubernetes à l’aide du certificat.

Activer la prise en charge TLS dans Citrix ADC pour l’application

Citrix Ingress Controller utilise la section TLS de la définition d’entrée comme activateur pour la prise en charge de TLS avec Citrix ADC.

Remarque :

En cas de certificat par défaut ou de certificats préconfigurés, vous devez ajouter un secret vide dans le champ spec.tls.secretname de votre définition d’entrée pour activer TLS.

L’exemple d’extrait de définition d’entrée suivant :

spec:
  tls:
  - secretName:
<!--NeedCopy-->

Générer un secret Kubernetes

Pour générer un secret Kubernetes pour un certificat existant, utilisez la commande kubectl suivante :

     kubectl create secret tls k8s-secret --cert=path/to/tls.cert --key=path/to/tls.key  --namespace=default

    secret “k8s-secret” created

La commande crée un secret Kubernetes avec un certificat au format PEM sous la clé tls.crt et une clé privée au format PEM sous la clé tls.key.

Vous pouvez également générer le secret Kubernetes à l’aide de la définition YAML suivante :

apiVersion: v1
kind: Secret
metadata:
  name: k8s-secret
data:
  tls.crt: base64 encoded cert
  tls.key: base64 encoded key
<!--NeedCopy-->

Déployez le YAML à l’aide de la commande kubectl -create <file-name>. Il crée un secret Kubernetes avec un certificat au format PEM sous tls.crt clé et une clé privée au format PEM sous tls.key clé.

Certificat par défaut du Citrix ingress controller

Le certificat par défaut du Citrix ingress controller est utilisé pour fournir un secret sur Kubernetes qui doit être utilisé en tant que certificat non SNI. Vous devez fournir le nom secret à utiliser et l’espace de noms à partir duquel il doit être pris en tant qu’arguments dans le fichier .yaml du Citrix ingress controller :

    --default-ssl-certificate <NAMESPACE>/<SECRET_NAME>

Voici un exemple de fichier de définition YAML du Citrix ingress controller qui contient un secret TLS (hotdrink.secret) sélectionné dans l’espace de noms ssl et fourni en tant que certificat par défaut du Citrix ingress controller.

Remarque :

L’ESPACE DE NOMS est obligatoire avec un SECRET_NAME valide.

apiVersion: v1
kind: Pod
metadata:
  name: cic
  labels:
    app: cic
spec:
  serviceAccountName: cpx
  containers:
  - name: cic
    image: "xxxx"
    imagePullPolicy: Always
    args:
    - --default-ssl-certificate
      ssl/hotdrink.secret
    env:
    # Set Citrix ADM Management IP
    - name: "NS_IP"
      value: "xx.xx.xx.xx"
    # Set port for Nitro
    - name: "NS_PORT"
      value: "xx"
    # Set Protocol for Nitro
    - name: "NS_PROTOCOL"
      value: "HTTP"
    # Set username for Nitro
    - name: "NS_USER"
      value: "nsroot"
    # Set user password for Nitro
    - name: "NS_PASSWORD"
      value: "nsroot"
<!--NeedCopy-->

Certificats préconfigurés

Le Citrix ingress controller vous permet d’utiliser les clés de certificat déjà configurées sur Citrix ADC. Vous devez fournir les détails concernant le certificat à l’aide de l’annotation suivante dans votre définition d’entrée :

    ingress.citrix.com/preconfigured-certkey : '{"certs": [ {"name": "<name>", "type": "default|sni|ca"} ] }'

Vous pouvez fournir des détails sur plusieurs certificats sous forme de liste dans l’annotation. Vous pouvez également définir la façon dont le certificat est traité. Dans l’exemple d’annotation suivant, certkey1 est utilisé en tant que certificat non-SNI et certkey2 en tant que certificat SNI :

    ingress.citrix.com/preconfigured-certkey : '{"certs": [ {"name": "certkey1", "type": "default"}, {"name": "certkey2", "type": "sni"} ] }’

Si le paramètre type n’est pas fourni avec le nom d’un certificat, il est considéré comme le type par défaut (non SNI).

Remarque :

Assurez-vous d’utiliser cette fonctionnalité dans les cas où vous souhaitez réutiliser les certificats présents sur Citrix ADC et les lier aux applications gérées par le Citrix ingress controller. Le Citrix ingress controller ne gère pas le cycle de vie des certificats. En d’autres termes, il ne crée ni ne supprime les certificats, mais les lie uniquement aux applications nécessaires.

Section TLS dans le YAML d’entrée

Kubernetes vous permet de fournir les secrets TLS dans la section spec: d’une définition d’entrée. Cette section décrit comment le Citrix ingress controller utilise ces secrets.

Avec la section d’accueil

Si le nom secret est fourni avec la section hôte, le Citrix ingress controller lie le secret en tant que certificat SNI.

spec:
  tls:
  - secretName: fruitjuice.secret
    hosts:
    - items.fruit.juice
<!--NeedCopy-->

Sans la section hôte

Si le nom secret est fourni sans la section hôte, le Citrix ingress controller lie le secret en tant que certificat par défaut.

spec:
  tls:
  - secretName: colddrink.secret
<!--NeedCopy-->

Remarque :

Si plusieurs secrets sont fournis, le Citrix ingress controller lie tous les certificats en tant que certificats activés SNI.

Points à noter

  1. Lorsque plusieurs secrets sont fournis au Citrix ingress controller, la priorité suivante est suivie :

    1. clé de certificat par défaut préconfigurée ou secret tls non hôte
    2. certificat-ssl par défaut
  2. En cas de conflit de priorité entre les certificats de même niveau (par exemple, deux fichiers d’entrée configurent chacun un secret TLS non hôte, en tant que type par défaut/non SNI), le Citrix ingress controller lie le certificat par défaut du Citrix ingress controller en tant que certificat non SNI et utilise tous les autres certificats avec SNI.

  3. Le certificat utilisé pour un secret donné en vertu de la section TLS doit porter un nom NC. Dans le cas contraire, il ne se lie pas à Citrix ADC.

  4. Si SNI est activé pour le serveur virtuel SSL, alors :

    • Un certificat non SNI (par défaut) est utilisé pour les demandes HTTPs suivantes :

       curl -1 -v -k https://1.1.1.1/
      
       curl -1 -v -k -H 'HOST:*.colddrink.beverages' https://1.1.1.1/
      
    • Le certificat activé SNI est utilisé pour une demande avec un nom de domaine complet :

       curl -1 -v -k https://items.colddrink.beverages/
      

      Si une demande qui ne correspond pas aux certificats est reçue, le nom de l’avis de modification échoue.

Gestion des certificats TLS dans le Citrix ingress controller