Ingress Controller de Citrix ADC

Implementar una aplicación web HTTPS en Kubernetes con el Citrix Ingress Controller y HashiCorp Vault mediante cert-manager

Para los recursos de entrada implementados con el Citrix Ingress Controller, puede automatizar el aprovisionamiento, la revocación y la renovación de certificados TLS mediante cert-manager y HashiCorp Vault. En este tema se proporciona un flujo de trabajo de ejemplo que utiliza HashiCorp Vault como una entidad de certificación autofirmada para las solicitudes de firma de certificados de cert-manager.

En concreto, el flujo de trabajo utiliza el motor de secretos de PKI de Vault para crear una entidad de certificación (CA). En este instructivo, se supone que tiene un servidor de Vault instalado y accesible desde el clúster de Kubernetes. El motor de secretos de PKI de Vault es adecuado para aplicaciones internas. Para aplicaciones externas que requieren confianza pública, consulte Automatización de certificados TLS mediante la CA de Let’s Encrypt.

El flujo de trabajo utiliza un motor secreto de Vault y métodos de autenticación. Para obtener una lista completa de las funciones de Vault, consulte la siguiente documentación de Vault:

En este tema se proporciona información sobre cómo implementar una aplicación web HTTPS en un clúster de Kubernetes, mediante:

Requisitos previos

Asegúrese de lo siguiente:

  • El servidor de Vault está instalado, abierto y se puede acceder a él desde el clúster de Kubernetes. Para obtener información sobre la instalación del servidor de Vault, consulte la documentación de instalación de Vault.

  • Se ha habilitado el RBAC en el clúster de Kubernetes.

  • Se implementó Citrix ADC MPX, VPX o CPX en el modelo de implementación de nivel 1 o nivel 2.

    En el modelo de implementación de nivel 1, Citrix ADC MPX o VPX se utiliza como Delivery Controller de aplicaciones (ADC). El Citrix Ingress Controller que se ejecuta en el clúster de Kubernetes configura los servicios virtuales para los servicios que se ejecutan en el clúster de Kubernetes. Citrix ADC ejecuta el servicio virtual en la dirección IP redirigible pública y descarga SSL para el tráfico de clientes con la ayuda del certificado generado por Let’s Encrypt.

    En la implementación de nivel 2, se configura un servicio TCP en Citrix ADC (VPX/MPX) que se ejecuta fuera del clúster de Kubernetes para reenviar el tráfico a las instancias de Citrix ADC CPX que se ejecutan en el clúster de Kubernetes. Citrix ADC CPX finaliza la sesión SSL y equilibra la carga del tráfico a los pods de servicio reales.

  • Citrix Ingress Controller implementado. Consulte Topologías de implementación para ver varios casos de implementación.

  • Permisos de administrador para todos los pasos de implementación. Si encuentra errores debido a los permisos, asegúrese de tener el permiso de administrador.

Nota:

El siguiente procedimiento muestra los pasos para configurar Vault como una entidad de certificación con Citrix ADC CPX utilizado como dispositivo de entrada. Cuando se utiliza un Citrix ADC VPX o MPX como dispositivo de entrada, los pasos son los mismos, excepto los pasos para verificar la configuración de entrada en Citrix ADC.

Implementar cert-manager mediante el archivo de manifiesto

Realice los siguientes pasos para implementar cert-manager mediante el archivo de manifiesto YAML suministrado.

  1. Instale cert-manager. Para obtener información sobre la instalación de cert-manager, consulte la documentación de cert-manager.

    kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/vx.x.x/cert-manager.yaml
    

    También puede instalar cert-manager con Helm. Para obtener más información, consulte la documentación de cert-manager.

  2. Verifique que cert-manager esté en funcionamiento con el siguiente comando.

    % kubectl -n cert-manager get all
    NAME                                       READY   STATUS    RESTARTS   AGE
    pod/cert-manager-77fd74fb64-d68v7          1/1     Running   0          4m41s
    pod/cert-manager-webhook-67bf86d45-k77jj   1/1     Running   0          4m41s
    
    NAME                           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
    service/cert-manager-webhook   ClusterIP   10.108.161.154   <none>        443/TCP   13d
    
    NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/cert-manager           1/1     1            1           13d
    deployment.apps/cert-manager-webhook   1/1     1            1           13d
    
    NAME                                             DESIRED   CURRENT   READY   AGE
    replicaset.apps/cert-manager-77fd74fb64          1         1         1       13d
    replicaset.apps/cert-manager-webhook-67bf86d45   1         1         1       13d
    
    NAME                                                COMPLETIONS   DURATION   AGE
    job.batch/cert-manager-webhook-ca-sync              1/1           22s        13d
    job.batch/cert-manager-webhook-ca-sync-1549756800   1/1           21s        10d
    job.batch/cert-manager-webhook-ca-sync-1550361600   1/1           19s        3d8h
    
    NAME                                         SCHEDULE   SUSPEND   ACTIVE   LAST SCHEDULE   AGE
    cronjob.batch/cert-manager-webhook-ca-sync   @weekly    False     0        3d8h            13d
    

Implementar una aplicación web de muestra

Realice los siguientes pasos para implementar una aplicación web de ejemplo.

Nota:

Sin embargo, una aplicación de demostración de Kubernetes se utiliza como referencia en este tema.

  1. Cree un archivo YAML de implementación (kuard-deployment.yaml) para Kuard con la siguiente configuración.

    
            apiVersion: apps/v1
            kind: Deployment
            metadata:
              name: kuard
            spec:
              replicas: 1
              selector:
                matchLabels:
                  app: kuard
              template:
                metadata:
                  labels:
                    app: kuard
                spec:
                  containers:
                  - image: gcr.io/kuar-demo/kuard-amd64:1
                    imagePullPolicy: Always
                    name: kuard
                    ports:
                    - containerPort: 8080
    <!--NeedCopy-->
    
  2. Implemente el archivo de implementación de Kuard (kuard-deployment.yaml) en su clúster con los siguientes comandos.

    % kubectl create -f kuard-deployment.yaml
    deployment.extensions/kuard created
    % kubectl get pod -l app=kuard
    NAME                     READY   STATUS    RESTARTS   AGE
    kuard-6fc4d89bfb-djljt   1/1     Running   0          24s
    
  3. Cree un servicio para la implementación. Cree un archivo llamado service.yaml con la siguiente configuración.

          apiVersion: v1
          kind: Service
          metadata:
            name: kuard
          spec:
            ports:
            - port: 80
              targetPort: 8080
              protocol: TCP
            selector:
              app: kuard
    <!--NeedCopy-->
    
  4. Implemente y verifique el servicio mediante el siguiente comando.

    % kubectl create -f service.yaml
    service/kuard created
    % kubectl get svc kuard
    NAME    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
    kuard   ClusterIP   10.103.49.171   <none>        80/TCP    13s
    
  5. Exponga este servicio al mundo exterior mediante la creación de un Ingress que se implementa en Citrix ADC CPX o VPX como servidor virtual de conmutación de contenido.

    Nota:

    Asegúrese de cambiar kubernetes.io/ingress.class a la clase de entrada en la que se inicia el Citrix Ingress Controller.

        apiVersion: networking.k8s.io/v1
        kind: Ingress
        metadata:
          annotations:
            kubernetes.io/ingress.class: citrix
          name: kuard
        spec:
          rules:
          - host: kuard.example.com
            http:
              paths:
              - backend:
                  service:
                    name: kuard
                    port:
                      number: 80
                path: /
                pathType: Prefix
     <!--NeedCopy-->
    

    Nota:

    Cambia el valor de spec.rules.host por el dominio que controlas. Asegúrese de que exista una entrada DNS para redirigir el tráfico a Citrix ADC CPX o VPX.

  6. Implemente el Ingress con el siguiente comando.

    % kubectl apply -f ingress.yml
    ingress.extensions/kuard created
    root@ubuntu-vivek-225:~/cert-manager# kubectl get ingress
    NAME    HOSTS               ADDRESS   PORTS   AGE
    kuard   kuard.example.com             80      7s
    
  7. Compruebe si la entrada está configurada en Citrix ADC CPX o VPX mediante el siguiente comando.

    kubectl exec -it cpx-ingress-5b85d7c69d-ngd72 /bin/bash
    root@cpx-ingress-5b85d7c69d-ngd72:/# cli_script.sh 'sh cs vs'
    exec: sh cs vs
    1) k8s-10.244.1.50:80:http (10.244.1.50:80) - HTTP Type: CONTENT
      State: UP
      Last state change was at Thu Feb 21 09:02:14 2019
      Time since last state change: 0 days, 00:00:41.140
      Client Idle Timeout: 180 sec
      Down state flush: ENABLED
      Disable Primary Vserver On Down : DISABLED
      Comment: uid=75VBGFO7NZXV7SCI4LSDJML2Q5X6FSNK6NXQPWGMDOYGBW2IMOGQ====
      Appflow logging: ENABLED
      Port Rewrite : DISABLED
      State Update: DISABLED
      Default: Content Precedence: RULE
      Vserver IP and Port insertion: OFF
      L2Conn: OFF Case Sensitivity: ON
      Authentication: OFF
      401 Based Authentication: OFF
      Push: DISABLED Push VServer:
      Push Label Rule: none
      Listen Policy: NONE
      IcmpResponse: PASSIVE
      RHIstate:  PASSIVE
      Traffic Domain: 0
    Done
    root@cpx-ingress-5b85d7c69d-ngd72:/# exit
    exit
    
  8. Compruebe si la página se está sirviendo correctamente cuando se solicita mediante el comando curl.

    % curl -sS -D - kuard.example.com -o /dev/null
    HTTP/1.1 200 OK
    Content-Length: 1458
    Content-Type: text/html
    Date: Thu, 21 Feb 2019 09:09:05 GMT
    

Una vez que haya implementado la aplicación HTTP de ejemplo, puede proceder a hacer que la aplicación esté disponible a través de HTTPS. Aquí, el servidor de Vault firma la CSR generada por el administrador de certificados y se genera automáticamente un certificado de servidor para la aplicación.

En el siguiente procedimiento, utilizará Vault configurado como entidad de certificación y configurará el administrador de certificados para que use Vault como autoridad de firma para la CSR.

Configurar HashiCorp Vault como entidad de certificación

En este procedimiento, configura una solicitud de firma de certificado de CA intermedia mediante HashiCorp Vault. El administrador de certificados utiliza este extremo de Vault para firmar el certificado de los recursos de entrada.

Nota:

Asegúrese de haber instalado la utilidad jq antes de realizar estos pasos.

Crear una CA raíz

Para el flujo de trabajo de muestra, puede generar su propia entidad de certificación raíz dentro de Vault. En un entorno de producción, debe usar una CA raíz externa para firmar la CA intermedia que Vault usa para generar certificados. Si tiene una CA raíz generada en otro lugar, omita este paso.

Nota:

PKI_ROOT es una ruta en la que se monta la CA raíz, por lo general pki. $ {DOMAIN} en este procedimiento es example.com


% export DOMAIN=example.com
% export PKI_ROOT=pki

% vault secrets enable -path="${PKI_ROOT}" pki

# Set the max TTL for the root CA to 10 years
% vault secrets tune -max-lease-ttl=87600h "${PKI_ROOT}"

% vault write -format=json "${PKI_ROOT}"/root/generate/internal \
 common_name="${DOMAIN} CA root" ttl=87600h | tee \
>(jq -r .data.certificate > ca.pem) \
>(jq -r .data.issuing_ca > issuing_ca.pem) \
>(jq -r .data.private_key > ca-key.pem)

#Configure the CA and CRL URLs:

% vault write "${PKI_ROOT}"/config/urls \
       issuing_certificates="${VAULT_ADDR}/v1/${PKI_ROOT}/ca" \
       crl_distribution_points="${VAULT_ADDR}/v1/${PKI_ROOT}/crl"
<!--NeedCopy-->

Generar una entidad de certificación intermedia

Después de crear la CA raíz, lleve a cabo los siguientes pasos para crear una CSR intermedia con la CA raíz.

  1. Por lo general, habilite pki desde una ruta diferente PKI_INT de la CA raíz pki\_int. Utilice el siguiente comando:

        % export PKI_INT=pki_int
        % vault secrets enable -path=${PKI_INT} pki
    
        # Set the max TTL to 3 year
    
        % vault secrets tune -max-lease-ttl=26280h ${PKI_INT}
       <!--NeedCopy-->
    
  2. Genere una CSR para ${DOMAIN} que la CA raíz debe firmar. La clave se almacena internamente en la bóveda. Utilice el siguiente comando:

          % vault write -format=json "${PKI_INT}"/intermediate/generate/internal \
          common_name="${DOMAIN} CA intermediate" ttl=26280h | tee \
          >(jq -r .data.csr > pki_int.csr) \
          >(jq -r .data.private_key > pki_int.pem)
    
       <!--NeedCopy-->
    
  3. Genere y firme el certificado ${DOMAIN} como CA intermedia mediante CA raíz, almacénelo como intermediate.cert.pem. Utilice el siguiente comando:

        % vault write -format=json "${PKI_ROOT}"/root/sign-intermediate csr=@pki_int.csr
                format=pem_bundle ttl=26280h \
                | jq -r '.data.certificate' > intermediate.cert.pem
      <!--NeedCopy-->
    

    Si utiliza una CA raíz externa, omita el paso anterior y firme la CSR manualmente con la CA raíz.

  4. Una vez que se firma la CSR y la CA raíz devuelve un certificado, es necesario volver a agregarlo a Vault mediante el siguiente comando:

        % vault write "${PKI_INT}"/intermediate/set-signed certificate=@intermediate.cert.pem
      <!--NeedCopy-->
    
  5. Establezca la ubicación de la CA y la CRL mediante el siguiente comando.

        vault write "${PKI_INT}"/config/urls issuing_certificates="${VAULT_ADDR}/v1/${PKI_INT}/ca" crl_distribution_points="${VAULT_ADDR}/v1/${PKI_INT}/crl"
      <!--NeedCopy-->
    

Se configura una CA intermedia que se puede usar para firmar certificados para los recursos de entrada.

Configurar un rol

Un rol es un nombre lógico que se asigna a las directivas. Un administrador puede controlar la generación de certificados a través de las funciones.

Cree una función para la CA intermedia que proporcione un conjunto de directivas para emitir o firmar los certificados con esta CA.

Hay muchas configuraciones que se pueden configurar al crear roles. Para obtener más información, consulta la documentación de la función de Vault.

Para el flujo de trabajo, cree una función kube-ingress que le permita firmar certificados de ${DOMAIN} y sus subdominios con un TTL de 90 días.

    # with a Max TTL of 90 days
    vault write ${PKI_INT}/roles/kube-ingress \
              allowed_domains=${DOMAIN} \
              allow_subdomains=true \
              max_ttl="2160h" \
              require_cn=false
  <!--NeedCopy-->

Crear autenticación basada en Apple

Después de configurar una CA intermedia para que firme los certificados, debe proporcionar un mecanismo de autenticación para que el administrador de certificados use Vault para firmar los certificados. Cert-Manager admite el método de autenticación de Approle, que proporciona una forma para que las aplicaciones accedan a las funciones definidas de Vault.

AppRole representa un conjunto de directivas de Vault y restricciones de inicio de sesión que deben cumplirse para recibir un token con esas directivas. Para obtener más información sobre este método de autenticación, consulte la documentación de Approle.

Crear un Apple

Cree un Approle llamado Kube-role. secret_id para el administrador de certificados no debe caducar para usar este Approle para la autenticación. Por lo tanto, no establezca un TTL ni lo establezca en 0.

% vault auth enable approle

% vault write auth/approle/role/kube-role token_ttl=0

Asociar una directiva con el Approle

Realice los siguientes pasos para asociar una directiva a un Approle.

  1. Cree un archivo pki_int.hcl con la siguiente configuración para permitir los puntos finales de firma de la CA intermedia.

        path "${PKI_INT}/sign/*" {
              capabilities = ["create","update"]
            }
    <!--NeedCopy-->
    
  2. Agregue el archivo a una nueva directiva llamada kube_allow_sign mediante el siguiente comando.

    vault policy write kube-allow-sign pki_int.hcl
    
  3. Actualice esta directiva en Approle mediante el siguiente comando.

    vault write auth/approle/role/kube-role policies=kube-allow-sign
    

El approle kube-role le permite firmar la CSR con una entidad de certificación intermedia.

Generar el ID de función y el ID secreto

El administrador de certificados utiliza el identificador de función y el identificador secreto para autenticarse en Vault.

Genere el ID de rol y el ID secreto y codifique el ID secreto con Base64. Lleve a cabo lo siguiente:

% vault read auth/approle/role/kube-role/role-id
role_id     db02de05-fa39-4855-059b-67221c5c2f63

% vault write -f auth/approle/role/kube-role/secret-id
secret_id               6a174c20-f6de-a53c-74d2-6018fcceff64
secret_id_accessor      c454f7e5-996e-7230-6074-6ef26b7bcf86

# encode secret_id with base64
% echo 6a174c20-f6de-a53c-74d2-6018fcceff64 | base64
NmExNzRjMjAtZjZkZS1hNTNjLTc0ZDItNjAxOGZjY2VmZjY0Cg==

Configurar la emisión de certificados en Kubernetes

Después de configurar Vault como CA intermedia y el método de autenticación de Approle para que el administrador de certificados acceda a Vault, debe configurar el certificado para la entrada.

Crea un secreto con el ID secreto de Approle

Realice lo siguiente para crear un secreto con el ID de secreto de Approle.

  1. Cree un archivo secreto llamado secretid.yaml con la siguiente configuración.

    apiVersion: v1
    kind: Secret
    type: Opaque
    metadata:
      name: cert-manager-vault-approle
      namespace: cert-manager
    data:
      secretId: "NmExNzRjMjAtZjZkZS1hNTNjLTc0ZDItNjAxOGZjY2VmZjY0Cg=="
    

    Nota:

    El identificador secreto data.secretId es el identificador secreto codificado en base64 generado en Generar el identificador de rol y el identificador secreto. Si utiliza un recurso Emisor en el siguiente paso, el secreto debe estar en el mismo espacio de nombres que Issuer. Para ClusterIssuer, el secreto debe estar en el espacio de nombres cert-manager.

  2. Implemente el archivo secreto (secretid.yaml) con el siguiente comando.

    % kubectl create -f secretid.yaml
    

Implementar el emisor del clúster de Vault

El administrador de certificados admite dos CRD diferentes para la configuración, an Issuer, que se aplica a un solo espacio de nombres, y a ClusterIssuer, que es de todo el clúster. Para el flujo de trabajo, debe usar ClusterIssuer.

Realice los siguientes pasos para implementar el emisor del clúster de Vault.

  1. Cree un archivo llamado issuer-vault.yaml con la siguiente configuración.

    apiVersion: cert-manager.io/v1
    kind: ClusterIssuer
    metadata:
      name: vault-issuer
    spec:
      vault:
        path: pki_int/sign/kube-ingress
        server: <vault-server-url>
        #caBundle: <base64 encoded caBundle PEM file>
        auth:
          appRole:
            path: approle
            roleId: "db02de05-fa39-4855-059b-67221c5c2f63"
            secretRef:
              name: cert-manager-vault-approle
              key: secretId
    

    SecretRef es el nombre secreto de Kubernetes creado en el paso anterior. Sustituya roleId por el role_id recuperado de la bóveda. Se puede proporcionar un CAbundle codificado en base64 opcional en formato PEM para validar la conexión TLS con Vault Server. Cuando se establece CAbundle, reemplaza el paquete de CA dentro del contenedor que ejecuta el administrador de certificados. Este parámetro no tiene efecto si la conexión utilizada está en HTTP simple.

  2. Implemente el archivo (issuer-vault.yaml) con el siguiente comando.

    % kubectl create -f issuer-vault.yaml
    
  3. Con el siguiente comando, compruebe si el emisor del clúster de Vault se ha autenticado correctamente con Vault.

    % kubectl describe clusterIssuer vault-issuer  | tail -n 7
      Conditions:
        Last Transition Time:  2019-02-26T06:18:40Z
        Message:               Vault verified
        Reason:                VaultVerified
        Status:                True
        Type:                  Ready
    Events:                    <none>
    

Ahora, ha configurado correctamente el administrador de certificados para Vault como CA. El siguiente paso es proteger la entrada generando el certificado del servidor. Hay dos opciones diferentes para proteger la entrada. Puede continuar con uno de los enfoques para asegurar sus ingresos.

  • Enfoque de corrección de entrada
  • Crear manualmente el objeto certificate CRD para el certificado.

Enfoque de entrada y corrección

En este enfoque, se modifica la anotación de entrada para que el administrador de certificados genere automáticamente el certificado para el nombre de host dado y lo almacene en el secreto especificado.

  1. Modifique la entrada con la sección tls especificando un nombre de host y un secreto. Además, especifique la anotación de cert-manager cert-manager.io/cluster-issuer de la siguiente manera.

            apiVersion: networking.k8s.io/v1
            kind: Ingress
            metadata:
              annotations:
                cert-manager.io/cluster-issuer: vault-issuer
                kubernetes.io/ingress.class: citrix
              name: kuard
            spec:
              rules:
              - host: kuard.example.com
                http:
                  paths:
                  - backend:
                      service:
                        name: kuard-service
                        port:
                          number: 80
                    path: /
                    pathType: Prefix
              tls:
              - hosts:
                - kuard.example.com
                secretName: kuard-example-tls
    <!--NeedCopy-->
    
  2. Implemente la entrada modificada de la siguiente manera.

      % kubectl apply -f ingress.yml
      ingress.extensions/kuard created
    
      % kubectl get ingress kuard
      NAME    HOSTS               ADDRESS   PORTS     AGE
      kuard   kuard.example.com             80, 443   12s
    

Este paso desencadena un objeto certificate por parte del administrador de certificados que crea una solicitud de firma de certificado (CSR) para el dominio kuard.example.com. Cuando se firma correctamente la CSR, el certificado se almacena en el nombre secreto kuard-example-tls especificado en la entrada.

  1. Compruebe que el certificado se haya emitido correctamente mediante el siguiente comando.

      % kubectl describe certificates kuard-example-tls  | grep -A5 Events
      Events:
      Type    Reason      Age   From          Message
      ----    ------      ----  ----          -------
      Normal  CertIssued  48s   cert-manager  Certificate issued successfully
    

Crear un objeto certificate CRD para el certificado

Una vez que el emisor se haya registrado correctamente, debe obtener el certificado para el dominio de entrada kuard.example.com.

Debe crear un recurso certificate con commonName y dnsNames. Para obtener más información, consulte la documentación de cert-manager. Puede especificar varios nombres de DNS que se utilizan para el campo SAN en el certificado.

Para crear un objeto CRD “certificado” para el certificado, lleve a cabo lo siguiente:

  1. Cree un archivo llamado certificate.yaml con la siguiente configuración.

    apiVersion: cert-manager.io/v1
    kind: Certificate
    metadata:
      name: kuard-example-tls
      namespace: default
    spec:
      secretName: kuard-example-tls
      issuerRef:
        kind: ClusterIssuer
        name: vault-issuer
      commonName: kuard.example.com
      duration: 720h
      #Renew before 7 days of expiry
      renewBefore: 168h
      commonName: kuard.example.com
      dnsNames:
      - www.kuard.example.com
    

    El certificado tiene CN=kuard.example.com y SAN=Kuard.example.com,www.kuard.example.com. spec.secretName es el nombre del secreto en el que se almacena el certificado después de que el certificado se haya emitido correctamente.

  2. Implemente el archivo (certificate.yaml) en el clúster de Kubernetes con el siguiente comando.

    Se ha creado% kubectl create -f certificate.yaml certificate.certmanager.k8s.io/kuard-example-tls

Verificar si se emite el certificado

Puede ver el progreso del certificado a medida que se emite mediante el siguiente comando:

% kubectl describe certificates kuard-example-tls  | grep -A5 Events
Events:
  Type    Reason      Age   From          Message
  ----    ------      ----  ----          -------
  Normal  CertIssued  48s   cert-manager  Certificate issued successfully > **Nota** > > Es posible que encuentres algunos errores debido a las directivas de Vault. Si encuentra algún error de este tipo, vuelva a la bóveda y arréglelo.

Después de firmar correctamente, se crea un secreto kubernetes.io/tls con el secretName especificado en el recurso Certificate.

% kubectl get secret kuard-example-tls
NAME                TYPE                DATA   AGE
kuard-exmaple-tls   kubernetes.io/tls   3      4m20s

Modificar la entrada para usar el secreto generado

Realice los siguientes pasos para modificar la entrada y usar el secreto generado.

  1. Modifique la entrada original y agregue una sección spec.tls que especifique el secreto de la kuard-example-tls siguiente manera.

          apiVersion: networking.k8s.io/v1
          kind: Ingress
          metadata:
            annotations:
              kubernetes.io/ingress.class: citrix
            name: kuard
          spec:
            rules:
            - host: kuard.example.com
              http:
                paths:
                - backend:
                    service:
                      name: kuard
                      port:
                        number: 80
                  pathType: Prefix
                  path: /
            tls:
            - hosts:
              - kuard.example.com
              secretName: kuard-example-tls
    
  2. Implemente la entrada mediante el siguiente comando.

    % kubectl apply -f ingress.yml
    ingress.extensions/kuard created
    
    % kubectl get ingress kuard
    NAME    HOSTS               ADDRESS   PORTS     AGE
    kuard   kuard.example.com             80, 443   12s
    

Comprobar la configuración de Ingress en Citrix ADC

Una vez que el certificado se genera correctamente, el Citrix Ingress Controller usa este certificado para configurar el servidor virtual SSL front-end. Puede verificarlo con los siguientes pasos.

  1. Inicie sesión en Citrix ADC CPX y compruebe si el certificado está enlazado al servidor virtual SSL.

    % kubectl exec -it cpx-ingress-668bf6695f-4fwh8 bash
    cli_script.sh 'shsslvs'
    exec: shsslvs
    1) Vserver Name: k8s-10.244.3.148:443:ssl
      DH: DISABLED
      DH Private-Key Exponent Size Limit: DISABLED Ephemeral RSA: ENABLED Refresh Count: 0
      Session Reuse: ENABLED Timeout: 120 seconds
      Cipher Redirect: DISABLED
      SSLv2 Redirect: DISABLED
      ClearText Port: 0
      Client Auth: DISABLED
      SSL Redirect: DISABLED
      Non FIPS Ciphers: DISABLED
      SNI: ENABLED
      OCSP Stapling: DISABLED
      HSTS: DISABLED
      HSTS IncludeSubDomains: NO
      HSTS Max-Age: 0
      SSLv2: DISABLED  SSLv3: ENABLED  TLSv1.0: ENABLED  TLSv1.1: ENABLED  TLSv1.2: ENABLED  TLSv1.3: DISABLED
      Push Encryption Trigger: Always
      Send Close-Notify: YES
      Strict Sig-Digest Check: DISABLED
      Zero RTT Early Data: DISABLED
      DHE Key Exchange With PSK: NO
      Tickets Per Authentication Context: 1
    Done
    
    root@cpx-ingress-668bf6695f-4fwh8:/# cli_script.sh 'shsslvs k8s-10.244.3.148:443:ssl'
    exec: shsslvs k8s-10.244.3.148:443:ssl
    
      Advanced SSL configuration for VServer k8s-10.244.3.148:443:ssl:
      DH: DISABLED
      DH Private-Key Exponent Size Limit: DISABLED Ephemeral RSA: ENABLED Refresh Count: 0
      Session Reuse: ENABLED Timeout: 120 seconds
      Cipher Redirect: DISABLED
      SSLv2 Redirect: DISABLED
      ClearText Port: 0
      Client Auth: DISABLED
      SSL Redirect: DISABLED
      Non FIPS Ciphers: DISABLED
      SNI: ENABLED
      OCSP Stapling: DISABLED
      HSTS: DISABLED
      HSTS IncludeSubDomains: NO
      HSTS Max-Age: 0
      SSLv2: DISABLED  SSLv3: ENABLED  TLSv1.0: ENABLED  TLSv1.1: ENABLED  TLSv1.2: ENABLED  TLSv1.3: DISABLED
      Push Encryption Trigger: Always
      Send Close-Notify: YES
      Strict Sig-Digest Check: DISABLED
      Zero RTT Early Data: DISABLED
      DHE Key Exchange With PSK: NO
      Tickets Per Authentication Context: 1
    , P_256, P_384, P_224, P_5216) CertKey Name: k8s-LMO3O3U6KC6WXKCBJAQY6K6X6JO Server Certificate for SNI
    
    7) Cipher Name: DEFAULT
      Description: Default cipher list with encryption strength >= 128bit
    Done
    
    root@cpx-ingress-668bf6695f-4fwh8:/# cli_script.sh 'sh certkey k8s-LMO3O3U6KC6WXKCBJAQY6K6X6JO'
    exec: sh certkey k8s-LMO3O3U6KC6WXKCBJAQY6K6X6JO
      Name: k8s-LMO3O3U6KC6WXKCBJAQY6K6X6JO Status: Valid,   Days to expiration:0
      Version: 3
      Serial Number: 524C1D9306F784A2F5277C05C2A120D5258D9A2F
      Signature Algorithm: sha256WithRSAEncryption
      Issuer:  CN=example.com CA intermediate
      Validity
        Not Before: Feb 26 06:48:39 2019 GMT
        Not After : Feb 27 06:49:09 2019 GMT
      Certificate Type: "Client Certificate" "Server Certificate"
      Subject:  CN=kuard.example.com
      Public Key Algorithm: rsaEncryption
      Public Key size: 2048
      Ocsp Response Status: NONE
      2) URI:http://127.0.0.1:8200/v1/pki_int/crl
      3) VServer name: k8s-10.244.3.148:443:ssl Server Certificate for SNI
    Done
    

    El servidor web HTTPS funciona con el certificado firmado del depósito. Cert-manager renueva automáticamente el certificado como se especifica en el parámetro RenewBefore del certificado, antes de que caduque el certificado.

    Nota:

    La firma de Vault del certificado falla si la caducidad de un certificado supera la caducidad de la CA raíz o la CA intermedia. Debe asegurarse de que los certificados de CA se renueven por adelantado antes de que caduquen.

  2. Compruebe que se puede acceder a la aplicación mediante el protocolo HTTPS.

    % curl -sS -D - https://kuard.example.com -k -o /dev/null
    HTTP/1.1 200 OK
    Content-Length: 1472
    Content-Type: text/html
    Date: Tue, 11 May 2021 20:39:23 GMT
    
Implementar una aplicación web HTTPS en Kubernetes con el Citrix Ingress Controller y HashiCorp Vault mediante cert-manager