Citrix ADC Ingress Controller

Handhabung von TLS-Zertifikaten im Citrix Ingress Controller

Citrix Ingress Controller bietet die Option zum Konfigurieren von TLS-Zertifikaten für Citrix ADC SSL-basierte virtuelle Server. Der virtuelle SSL-Server fängt den SSL-Verkehr ab, entschlüsselt ihn und verarbeitet ihn, bevor er an Dienste gesendet wird, die an den virtuellen Server gebunden sind.

Standardmäßig kann der virtuelle SSL-Server an ein Standardzertifikat binden, und die Anwendung empfängt den Datenverkehr basierend auf der an das Zertifikat gebundenen Richtlinie. Sie haben jedoch die Option Server Name Indication (SNI), um mehrere Zertifikate an einen einzelnen virtuellen Server zu binden. Citrix ADC bestimmt basierend auf dem Domänennamen im TLS-Handshake, welches Zertifikat dem Client präsentiert werden soll.

Der Citrix Ingress Controller verarbeitet die Zertifikate auf die folgenden drei Arten:

Voraussetzung

Um TLS-Zertifikate mit Citrix Ingress Controller zu verarbeiten, müssen Sie die TLS-Unterstützung in Citrix ADC für die Anwendung aktivieren. Wenn Sie Zertifikate in Ihrer Kubernetes-Bereitstellung verwenden, müssen Sie Kubernetes-Schlüssel mithilfe des Zertifikats generieren.

TLS-Unterstützung in Citrix ADC für die Anwendung aktivieren

Citrix Ingress Controller verwendet den TLS-Abschnitt in der Ingress-Definition als Enabler für die TLS-Unterstützung mit Citrix ADC.

Hinweis:

Im Fall von Standardzertifikat oder vorkonfigurierten Zertifikaten müssen Sie ein leeres Geheimnis im Feld spec.tls.secretname in Ihrer Eingangsdefinition hinzufügen, um TLS zu aktivieren.

Das folgende Beispiel-Snippet der Ingress-Definition:

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

Generieren Sie ein Kubernetes-Geheimnis

Verwenden Sie den folgenden kubectl Befehl, um einen Kubernetes-Schlüssel für ein vorhandenes Zertifikat zu generieren:

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

    secret “k8s-secret” created

Der Befehl erstellt ein Kubernetes-Secret mit einem PEM-formatierten Zertifikat unter dem tls.crt Schlüssel und einem PEM-formatierten privaten Schlüssel unter dem tls.key Schlüssel.

Alternativ können Sie das Kubernetes-Geheimnis auch mit der folgenden YAML-Definition generieren:

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

Stellen Sie die YAML mit dem kubectl -create <file-name> Befehl bereit. Es erstellt ein Kubernetes-Geheimnis mit einem PEM-formatierten Zertifikat unter dem tls.crt Schlüssel und einem PEM-formatierten privaten Schlüssel unter dem tls.key Schlüssel.

Citrix Ingress Controller-Standardzertifikat

Das Citrix Ingress Controller-Standardzertifikat wird verwendet, um ein Geheimnis in Kubernetes bereitzustellen, das als Nicht-SNI-Zertifikat verwendet werden muss. Sie müssen den zu verwendenden geheimen Namen und den Namespace, aus dem er als Argumente entnommen werden soll, in der .yaml Datei des Citrix Ingress Controller angeben:

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

Im Folgenden finden Sie ein Beispiel für eine YAML-Definitionsdatei für den Citrix Ingress Controller, die einen TLS-Schlüssel (hotdrink.secret) enthält, der aus dem ssl Namespace ausgewählt und als Standardzertifikat des Citrix Ingress Controller bereitgestellt wird.

Hinweis:

NAMESPACE ist zusammen mit einem gültigen SECRET_NAME erforderlich.

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-->

Vorkonfigurierte Zertifikate

Mit dem Citrix Ingress Controller können Sie die Certkeys verwenden, die bereits auf dem Citrix ADC konfiguriert sind. Sie müssen die Details zum Zertifikat mithilfe der folgenden Anmerkung in Ihrer Ingress-Definition angeben:

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

Sie können Details zu mehreren Zertifikaten als Liste in der Anmerkung angeben. Sie können auch festlegen, wie das Zertifikat behandelt wird. In der folgenden Beispielanmerkung wird certkey1 als Nicht-SNI-Zertifikat und certkey2 wird als SNI-Zertifikat verwendet:

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

Wenn der Typparameter nicht mit dem Namen eines Zertifikats versehen ist, wird er als Standardtyp (Nicht-SNI) betrachtet.

Hinweis:

Stellen Sie sicher, dass Sie diese Funktion in Fällen verwenden, in denen Sie die auf dem Citrix ADC vorhandenen Zertifikate wiederverwenden und an die Anwendungen binden möchten, die von Citrix Ingress Controller verwaltet werden. Citrix Ingress Controller verwaltet den Lebenszyklus der Zertifikate nicht. Das heißt, es erstellt oder löscht die Zertifikate nicht, sondern bindet sie nur an die erforderlichen Anwendungen.

TLS-Abschnitt im Ingress YAML

Mit Kubernetes können Sie die TLS-Geheimnisse im spec: Abschnitt einer Ingress-Definition angeben. In diesem Abschnitt wird beschrieben, wie der Citrix Ingress Controller diese geheimen Schlüssel verwendet.

Mit dem Host-Bereich

Wenn der geheime Name mit dem Host-Abschnitt bereitgestellt wird, bindet Citrix Ingress Controller das Geheimnis als SNI-Zertifikat.

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

Ohne den Host-Bereich

Wenn der geheime Name ohne den Host-Abschnitt angegeben wird, bindet Citrix Ingress Controller das Geheimnis als Standardzertifikat.

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

Hinweis:

Wenn mehr als ein Secret angegeben ist, bindet der Citrix Ingress Controller alle Zertifikate als SNI-fähige Zertifikate.

Wichtige Hinweise

  1. Wenn dem Citrix Ingress Controller mehrere geheime Schlüssel zur Verfügung gestellt werden, gilt folgende Priorität:

    1. preconfigured-default-certkey oder non-host tls secret
    2. default-ssl-certificate
  2. Wenn zwischen denselben Klassenzertifikaten ein Prioritätskonflikt besteht (z. B. konfigurieren zwei Eingangsdateien jeweils einen TLS-Schlüssel ohne Host als Standard-/Nicht-SNI-Typ), bindet der Citrix Ingress Controller das Standardzertifikat des Citrix Ingress Controller als das Nicht-SNI-Zertifikat und verwendet alle anderen zertifikate mit SNI.

  3. Das Zertifikat, das für ein im TLS-Abschnitt angegebenes Geheimnis verwendet wird, muss einen CN-Namen haben. Andernfalls wird es nicht an Citrix ADC gebunden.

  4. Wenn SNI für den virtuellen SSL-Server aktiviert ist, dann:

    • Ein Nicht-SNI-Zertifikat (Standard) wird für die folgenden HTTPS-Anforderungen verwendet:

       curl -1 -v -k https://1.1.1.1/
      
       curl -1 -v -k -H 'HOST:*.colddrink.beverages' https://1.1.1.1/
      
    • SNI-fähiges Zertifikat wird für eine Anforderung mit vollständigem Domainnamen verwendet:

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

      Wenn eine Anfrage eingeht, die nicht mit Zertifikaten übereinstimmt, schlägt der CN-Name fehl.

Handhabung von TLS-Zertifikaten im Citrix Ingress Controller