Ingress Controller de Citrix ADC

Manejo de certificados TLS en el Citrix Ingress Controller

El Citrix Ingress Controller ofrece la opción de configurar certificados TLS para servidores virtuales basados en SSL de Citrix ADC. El servidor virtual SSL intercepta el tráfico SSL, lo descifra y lo procesa antes de enviarlo a los servicios que están enlazados al servidor virtual.

De forma predeterminada, el servidor virtual SSL puede vincularse a un certificado predeterminado y la aplicación recibe el tráfico en función de la directiva enlazada al certificado. Sin embargo, tiene la opción Indicación de nombre de servidor (SNI) para vincular varios certificados a un único servidor virtual. Citrix ADC determina qué certificado debe presentar al cliente en función del nombre de dominio en el protocolo de enlace TLS.

El Citrix Ingress Controller administra los certificados de las siguientes tres maneras:

Requisito previo

Para administrar certificados TLS mediante el Citrix Ingress Controller, debe habilitar la compatibilidad con TLS en Citrix ADC para la aplicación y, además, si usa certificados en su implementación de Kubernetes, debe generar un secreto de Kubernetes con el certificado.

Habilitar la compatibilidad con TLS en Citrix ADC para la aplicación

Citrix Ingress Controller utiliza la sección TLS en la definición de entrada como habilitador para la compatibilidad con TLS con Citrix ADC.

Nota:

En el caso del certificado predeterminado o los certificados preconfigurados, debe agregar un secreto vacío en el campo spec.tls.secretname en la definición de entrada para habilitar TLS.

El siguiente fragmento de ejemplo de la definición de entrada:

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

Generar secreto de Kubernetes

Para generar un secreto de Kubernetes para un certificado existente, use el siguiente comando kubectl:

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

    secret “k8s-secret” created

El comando crea un secreto de Kubernetes con un certificado con formato PEM en la clave tls.crt y una clave privada con formato PEM en la clave tls.key.

Como alternativa, también puede generar el secreto de Kubernetes con la siguiente definición de YAML:

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

Implemente YAML mediante el comando kubectl -create <file-name>. Crea un secreto de Kubernetes con un certificado con formato PEM en la clave tls.crt y una clave privada con formato PEM en la clave tls.key.

Certificado predeterminado de Citrix Ingress Controller

El certificado predeterminado del Citrix Ingress Controller se usa para proporcionar un secreto en Kubernetes que debe usarse como certificado no SNI. Debe proporcionar el nombre secreto que se utilizará y el espacio de nombres del que se debe tomar como argumentos en el archivo .yaml del Citrix Ingress Controller:

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

A continuación, se muestra un archivo de definición YAML de Citrix Ingress Controller que contiene un secreto de TLS (hotdrink.secret) seleccionado del espacio de nombres ssl y que se proporciona como certificado predeterminado del Citrix Ingress Controller.

Nota:

NAMESPACE es obligatorio junto con un SECRET_NAME válido.

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

Certificados preconfigurados

Citrix Ingress Controller le permite usar las certkeys que ya están configuradas en Citrix ADC. Debe proporcionar los detalles sobre el certificado mediante la siguiente anotación en la definición de entrada:

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

Puede proporcionar detalles sobre varios certificados como una lista dentro de la anotación. Además, puede definir la forma en que se trata el certificado. En la siguiente anotación de ejemplo, certkey1 se usa como certificado no SNI y certkey2 se usa como certificado SNI:

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

Si el parámetro type no se proporciona con el nombre de un certificado, se considera el tipo predeterminado (no SNI).

Nota:

Asegúrese de utilizar esta función en los casos en que quiera reutilizar los certificados que están presentes en Citrix ADC y vincularlos a las aplicaciones administradas por el Citrix Ingress Controller. Citrix Ingress Controller no administra el ciclo de vida de los certificados. Es decir, no crea ni elimina los certificados, sino que solo los vincula a las aplicaciones necesarias.

Sección TLS en el YAML de entrada

Kubernetes le permite proporcionar los secretos de TLS en la sección spec: de una definición de entrada. En esta sección se describe cómo el Citrix Ingress Controller usa estos secretos.

Con la sección host

Si el nombre secreto se proporciona con la sección host, el Citrix Ingress Controller vincula el secreto como un certificado SNI.

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

Sin la sección de acogida

Si el nombre secreto se proporciona sin la sección de host, el Citrix Ingress Controller vincula el secreto como un certificado predeterminado.

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

Nota:

Si se proporciona más de un secreto, el Citrix Ingress Controller vincula todos los certificados como certificados habilitados para SNI.

Puntos que tener en cuenta

  1. Cuando se proporcionan varios secretos al Citrix Ingress Controller, se sigue la siguiente prioridad:

    1. clave de certificado predeterminada preconfigurada o secreto tls que no es de host
    2. certificado-ssl-predeterminado
  2. Si hay un conflicto de precedencia entre los mismos certificados de grado (por ejemplo, dos archivos de entrada configuran un secreto TLS no host cada uno, como de tipo predeterminado/no SNI), el Citrix Ingress Controller vincula el certificado predeterminado del Citrix Ingress Controller como el certificado no SNI y utiliza todos los demás certificados con el SNI.

  3. El certificado utilizado para un secreto dado en la sección TLS debe tener un nombre CN. De lo contrario, no se vincula a Citrix ADC.

  4. Si el SNI está habilitado para el servidor virtual SSL, entonces:

    • El certificado no SNI (predeterminado) se utiliza para las siguientes solicitudes HTTP:

       curl -1 -v -k https://1.1.1.1/
      
       curl -1 -v -k -H 'HOST:*.colddrink.beverages' https://1.1.1.1/
      
    • El certificado habilitado para SNI se usa para una solicitud con nombre de dominio completo:

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

      Si se recibe cualquier solicitud que no coincida con los certificados, el nombre CN falla.

Manejo de certificados TLS en el Citrix Ingress Controller