Ingress Controller de Citrix ADC

Implemente la aplicación web HTTPS en Kubernetes con el Citrix Ingress Controller y Let`s Encrypt mediante cert-manager

Let’s Encrypt y el protocolo ACME (Entorno de administración automática de certificados) le permite configurar un servidor HTTPS y obtener automáticamente un certificado de confianza del explorador. Para obtener un certificado para el dominio de su sitio web de Let’s Encrypt, debe demostrar el control sobre el dominio al cumplir ciertos desafíos. Un desafío forma parte de una lista de tareas específicas que solo alguien que controla el dominio puede realizar.

Actualmente hay dos tipos de desafíos:

  • Desafío HTTP-01: los desafíos HTTP-01 se completan publicando un archivo específico en una ubicación específica en un sitio web. La CA de Let’s Encrypt verifica el archivo realizando una solicitud HTTP en el URI HTTP para satisfacer el desafío.

  • Desafío de DNS-01: los desafíos de DNS01 se completan al proporcionar una clave calculada que está presente en un registro TXT de DNS. Una vez que este registro TXT se ha propagado a través de Internet, el servidor ACME puede recuperar correctamente esta clave mediante una búsqueda de DNS. El servidor ACME puede validar que el cliente es propietario del dominio para el certificado solicitado. Con los permisos correctos, cert-manager presenta automáticamente este registro TXT para su proveedor de DNS especificado.

Al validar correctamente el desafío, se otorga un certificado para el dominio.

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

Requisitos previos

Asegúrese de lo siguiente:

  • El dominio para el que se solicita el certificado es de acceso público.
  • Se ha habilitado el RBAC en el clúster de Kubernetes.
  • Se implementó Citrix ADC MPX, VPX o CPX implementado 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 el modelo de implementación de nivel 2, se configura un servicio TCP en Citrix ADC (VPX/MPX) que se ejecuta fuera del clúster de Kubernetes. Este servicio se crea 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.

  • Se implementó el Citrix Ingress Controller. Haga clic aquí para ver varios casos de implementación.

  • Se abrió el puerto 80 para la dirección IP virtual en el firewall para que la CA de Let’s Encrypt valide el dominio para el desafío HTTP01.

  • Un dominio DNS que usted controla, donde aloja su aplicación web para el desafío ACME DNS01.

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

Instalar cert-manager

Para instalar cert-manager, consulte la documentación de instalación de cert-manager.

Puede instalar cert-manager con archivos de manifiesto o gráfico de Helm.

Una vez que instale el cert-manager, verifique que cert-manager esté en funcionamiento como se explica al verificar la instalación.

Implementar una aplicación web de muestra

Realice lo siguiente 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:
              labels:
                app: kuard
              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
                      protocol: TCP
    <!--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 los siguientes comandos:

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

    Garantiza que cambie el valor de 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
    

Nota:

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

  1. Implemente Ingress con el siguiente comando:

    % kubectl apply -f ingress.yml
    ingress.extensions/kuard created
    
    root@ubuntu-:~/cert-manager# kubectl get ingress
    NAME    HOSTS               ADDRESS   PORTS   AGE
    kuard   kuard.example.com             80      7s
    
  2. Compruebe que Ingress esté configurado en Citrix ADC CPX o VPX mediante el siguiente comando:

    $ kubectl exec -it cpx-ingress-5b85d7c69d-ngd72 /bin/bash
    
    root@cpx-ingress-55c88788fd-qd4rg:/# cli_script.sh 'show cs vserver'
    exec: show cs vserver
    1)  k8s-192.168.8.178_80_http (192.168.8.178:80) - HTTP Type: CONTENT
      State: UP
      Last state change was at Sat Jan  4 13:36:14 2020
      Time since last state change: 0 days, 00:18:01.950
      Client Idle Timeout: 180 sec
      Down state flush: ENABLED
      Disable Primary Vserver On Down : DISABLED
      Comment: uid=MPPL57E3AFY6NMNDGDKN2VT57HEZVOV53Z7DWKH44X2SGLIH4ZWQ====
      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
      Persistence: NONE
      Listen Policy: NONE
      IcmpResponse: PASSIVE
      RHIstate:  PASSIVE
      Traffic Domain: 0
    Done
    
    root@cpx-ingress-55c88788fd-qd4rg/# exit
    exit
    
  3. Verifique que la página web se esté sirviendo correctamente cuando se solicite 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
    

Configurar la emisión del certificado ACME mediante el desafío HTTP

En esta sección se describe una forma de emitir el certificado ACME mediante la validación HTTP. Si quiere utilizar la validación de DNS, omita esta sección y continúe con la siguiente sección.

La validación HTTP con cert-manager es una forma sencilla de obtener un certificado de Let’s Encrypt para su dominio. En este método, demuestra la propiedad de un dominio asegurándose de que un archivo en particular esté presente en el dominio. Se supone que usted controla el dominio si puede publicar el archivo dado en una ruta determinada.

Implementar el ClusterIssuer de Let’s Encrypt con el proveedor de desafíos HTTP01

El administrador de certificados admite dos CRD diferentes para la configuración, una Issuer, con un alcance para un solo espacio de nombres y una ClusterIssuer, con alcance para todo el clúster.

Para que el Citrix Ingress Controller use Ingress desde cualquier espacio de nombres, use ClusterIssuer. Como alternativa, también puede crear un espacio de nombres Issuer para cada espacio de nombres en el que cree un recurso de Ingress.

Para obtener más información, consulte la documentación de cert-manager para la validación HTTP.

  1. Cree un archivo llamado issuer-letsencrypt-staging.yaml con la siguiente configuración:

    apiVersion: cert-manager.io/v1alpha2
    kind: ClusterIssuer
    metadata:
      name: letsencrypt-staging
    spec:
      acme:
        # You must replace this email address with your own.
        # Let's Encrypt will use this to contact you about expiring
        # certificates, and issues related to your account.
        email: user@example.com
        server: https://acme-staging-v02.api.letsencrypt.org/directory
        privateKeySecretRef:
          # Secret resource used to store the account's private key.
          name: example-issuer-account-key
        # Add a single challenge solver, HTTP01 using citrix
        solvers:
        - http01:
            ingress:
              class: citrix
    

    spec.acme.solvers[].http01.ingress.class se refiere a la clase Ingress del controlador de entrada de Citrix. Si el Citrix Ingress Controller no tiene clase de entrada, no necesita especificar este campo. Nota: Este es un ejemplo Clusterissuer del recurso cert-manager.io/v1alpha2. Para obtener más información, consulte la documentación de cert-manager http01.

    El servidor provisional Let’s Encrypt emite un certificado falso, pero no está sujeto a los límites de velocidad de la API del servidor de producción. Este enfoque le permite configurar y probar su entorno sin preocuparse por los límites de velocidad. Puede repetir el mismo paso para el servidor de producción de Let’s Encrypt.

  2. Después de modificar y guardar el archivo, implemente el archivo con el siguiente comando:

    % kubectl apply -f issuer-letsencrypt-staging.yaml
    clusterissuer "letsencrypt-staging" created
    
  3. Compruebe que el emisor se ha creado y registrado en el servidor ACME.

    % kubectl get issuer
    NAME                  AGE
    letsencrypt-staging   8d
    
  4. Compruebe que ClusterIssuer se ha registrado correctamente mediante el comando kubectl describe issuer letsencrypt-staging:

    % kubectl describe issuer letsencrypt-staging
    
    Status:
      Acme:
        Uri:  https://acme-staging-v02.api.letsencrypt.org/acme/acct/8200869
      Conditions:
        Last Transition Time:  2019-02-11T12:06:31Z
        Message:               The ACME account was registered with the ACME server
        Reason:                ACMEAccountRegistered
        Status:                True
        Type:                  Ready
    

Emitir certificado para el objeto Ingress

Una vez que ClusterIssuer se haya registrado correctamente, puede obtener un certificado para el dominio de entrada ‘kuard.ejemplo.com’.

Puede solicitar un certificado para el recurso Ingress especificado mediante los siguientes métodos:

  • Agregar anotaciones Ingress-shim al objeto de entrada.

  • Creación de un objeto certificate CRD.

El primer método es rápido y sencillo, pero si necesita más personalización y granularidad en términos de renovación de certificados, puede elegir el segundo método. Puede elegir el método de acuerdo a sus necesidades.

Agregar anotaciones Ingress-shim al objeto Ingress

En este enfoque, agrega las dos anotaciones siguientes al objeto Ingress para el que solicita un certificado del servidor ACME.

certmanager.io/cluster-issuer: "letsencrypt-staging"

Nota:

Puede encontrar todas las anotaciones admitidas en cert-manager for Ingress-shim, en anotaciones compatibles.

Además, modifique ingress.yaml para usar TLS especificando un secreto.

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    annotations:
      certmanager.io/cluster-issuer: letsencrypt-staging
      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

La anotación cert-manager.io/cluster-issuer: "letsencrypt-staging" indica a cert-manager que use el emisor de todo el clúster letsencrypt-staging para solicitar un certificado de los servidores de preparación de Let’s Encrypt. Cert-manager crea un objeto certificate que se usa para administrar el ciclo de vida del certificado para kuard.example.com. El valor del nombre de dominio y el método de desafío para el objeto de certificado se deriva del objeto de entrada. Cert-manager administra el contenido del secreto siempre que el Ingress esté presente en su clúster.

Implemente el archivo ingress.yaml con el siguiente comando:

% kubectl apply -f ingress.yml

ingress.extensions/kuard configured
% kubectl get ingress kuard
NAME    HOSTS               ADDRESS   PORTS     AGE
kuard   kuard.example.com             80, 443   4h39m

Crear un recurso CRD de certificado

Como alternativa, puede implementar un objeto CRD de certificado independiente del objeto Ingress. La documentación del CRD de “certificado” se puede encontrar en la validación HTTP.

  1. Cree el archivo certificate.yaml con la siguiente configuración:
        apiVersion: cert-manager.io/v1alpha2
        kind: Certificate
        metadata:
          name: example-com
          namespace: default
        spec:
          secretName: kuard-example-tls
          issuerRef:
            name: letsencrypt-staging
          commonName: kuard.example.com
          dnsNames:
          - www.kuard.example.com
   <!--NeedCopy-->

La spec.secretName clave es el nombre del secreto en el que se almacena el certificado cuando se emite correctamente el certificado.

  1. Implementa el archivo certificate.yaml en el clúster de Kubernetes:

    kubectl create -f certificate.yaml
    certificate.cert-manager.io/example-com created
    
  2. Verifique que el administrador de certificados cree el recurso personalizado del certificado que representa el certificado especificado en Ingress. Después de unos minutos, si la validación de ACME va bien, el estado del certificado “LISTO” se establece en verdadero.

    % kubectl get certificates.cert-manager.io kuard-example-tls
    NAME                READY   SECRET              AGE
    kuard-example-tls   True    kuard-example-tls   3m44s
    
    
    % kubectl get certificates.cert-manager.io kuard-example-tls
    Name:         kuard-example-tls
    Namespace:    default
    Labels:       <none>
    Annotations:  <none>
    API Version:  cert-manager.io/v1alpha2
    Kind:         Certificate
    Metadata:
      Creation Timestamp:  2020-01-04T17:36:26Z
      Generation:          1
      Owner References:
        API Version:           extensions/v1beta1
        Block Owner Deletion:  true
        Controller:            true
        Kind:                  Ingress
        Name:                  kuard
        UID:                   2cafa1b4-2ef7-11ea-8ba9-06bea3f4b04a
      Resource Version:        81263
      Self Link:               /apis/cert-manager.io/v1alpha2/namespaces/default/certificates/kuard-example-tls
      UID:                     bbfa5e51-2f18-11ea-8ba9-06bea3f4b04a
    Spec:
      Dns Names:
        acme.cloudpst.net
      Issuer Ref:
        Group:      cert-manager.io
        Kind:       ClusterIssuer
        Name:       letsencrypt-staging
      Secret Name:  kuard-example-tls
    Status:
      Conditions:
        Last Transition Time:  2020-01-04T17:36:28Z
        Message:               Certificate is up to date and has not expired
        Reason:                Ready
        Status:                True
        Type:                  Ready
      Not After:               2020-04-03T16:36:27Z
    Events:
      Type    Reason        Age   From          Message
      ----    ------        ----  ----          -------
      Normal  GeneratedKey  24m   cert-manager  Generated a new private key
      Normal  Requested     24m   cert-manager  Created new CertificateRequest resource "kuard-example-tls-3030465986"
      Normal  Issued        24m   cert-manager  Certificate issued successfully
    
  3. Compruebe que se ha creado el recurso secreto.

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

Emisión de un certificado ACME mediante el desafío de DNS

En esta sección se describe una forma de utilizar la validación de DNS para obtener el certificado ACME de la CA de Let’sEncrypt. Con un desafío de DNS-01, usted demuestra la propiedad de un dominio al demostrar que controla sus registros de DNS. Esto se hace creando un registro TXT con contenido específico que demuestre que tiene el control de los registros DNS del dominio. Para obtener una explicación detallada del desafío del DNS y las mejores prácticas de seguridad en la implementación del desafío del DNS, consulte Una inmersión técnica profunda: asegurar la automatización de la validación del desafío del DNS de ACME.

Nota:

En este procedimiento, route53 se utiliza como proveedor de DNS. Para otros proveedores, consulte la documentación de cert-manager de validación de DNS.

Implementar el ClusterIssuer de Let’s Encrypt con el proveedor de desafíos DNS01

Realice lo siguiente para implementar Let’s Encrypt ClusterIssuer con el proveedor de desafíos DNS01:

  1. Cree una cuenta de usuario de AWS IAM y descargue el ID de la clave de acceso secreta y la clave de acceso secreta.
  2. Otorgue la siguiente directiva de IAM a su usuario:

    Directiva de acceso de Route53

  3. Crea un secreto de Kubernetes acme-route53 en el espacio de nombres kube-system.

    % kubectl create secret generic acme-route53 --from-literal secret-access-key=<secret_access_key>
    
  4. Cree un Issuer o ClusterIssuer con el proveedor de desafíos DNS01.

    Puede proporcionar varios proveedores en DNS01 y especificar qué proveedor se utilizará en el momento de la creación del certificado. Debe tener acceso al proveedor de DNS para que cert-manager cree un registro TXT. Las credenciales se almacenan en el secreto de Kubernetes especificado en spec.dns01.secretAccessKeySecretRef. Para obtener instrucciones detalladas sobre cómo obtener credenciales, consulte la documentación del proveedor de DNS.

          apiVersion: cert-manager.io/v1alpha2
          kind: ClusterIssuer
          metadata:
            name: letsencrypt-staging
            spec:
              acme:
              # You must replace this email address with your own.
              # Let's Encrypt will use this to contact you about expiring
              # certificates, and issues related to your account.
                email: user@example.com
                server: https://acme-staging-v02.api.letsencrypt.org/directory
                privateKeySecretRef:
                  name: example-issuer-account-key
                solvers:
                - dns01:
                    route53:
                      region: us-west-2
                      accessKeyID: <IAMKEY>
                      secretAccessKeySecretRef:
                        name: acme-route53
                        key: secret-access-key
    <!--NeedCopy-->
    

    Nota:

    Sustituya user@example.com por su dirección de correo electrónico. Para cada dominio mencionado en una estrofa de DNS01, cert-manager usa las credenciales del proveedor del emisor al que se hace referencia para crear un registro TXT llamado _acme-challenge. A continuación, el servidor ACME verifica este registro para emitir el certificado. Para obtener más información sobre la configuración del proveedor de DNS y la lista de proveedores compatibles, consulte el documento de referencia de DNS01.

  5. Después de modificar y guardar el archivo, implemente el archivo con el siguiente comando:

    % kubectl apply -f acme_clusterissuer_dns.yaml
    clusterissuer "letsencrypt-staging" created
    
  6. Compruebe si el emisor se ha creado y registrado en el servidor ACME mediante el siguiente comando:

    % kubectl get issuer
    NAME                  AGE
    letsencrypt-staging   8d
    
  7. Compruebe si ClusterIssuer está registrado correctamente mediante el comando kubectl describe issuer letsencrypt-staging:

    Status:
      Acme:
        Uri:  https://acme-staging-v02.api.letsencrypt.org/acme/acct/8200869
      Conditions:
        Last Transition Time:  2019-02-11T12:06:31Z
        Message:               The ACME account was registered with the ACME server
        Reason:                ACMEAccountRegistered
        Status:                True
        Type:                  Ready
    

Emitir certificado para el recurso Ingress

Una vez que el emisor se haya registrado correctamente, puede obtener un certificado para el dominio de entrada kuard.example.com. Al igual que en el desafío HTTP01, hay dos formas de solicitar el certificado para un recurso Ingress específico:

Agregar anotaciones Ingress-shim al objeto Ingress

Agregue la siguiente anotación al objeto Ingress junto con la sección spec.tls:

certmanager.io/cluster-issuer: "letsencrypt-staging"
<!--NeedCopy-->
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-staging
    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
<!--NeedCopy-->

El administrador de certificados crea un recurso Certificate CRD con el desafío DNS01. Utiliza las credenciales especificadas en ClusterIssuer para crear un registro TXT en el servidor DNS para el dominio del que es propietario. A continuación, Let’s Encrypt CA valida el contenido del registro TXT para completar el desafío.

Agregar un recurso CRD Certificate**

Como alternativa, puede crear explícitamente un recurso de definición de recursos personalizados de certificados para desencadenar la generación automática de certificados.

  1. Cree el archivo certificate.yaml con la siguiente configuración:

            apiVersion: cert-manager.io/v1alpha2
            kind: Certificate
            metadata:
              name: example-com
              namespace: default
            spec:
              secretName: kuard-example-tls
              issuerRef:
                name: letsencrypt-staging
              commonName: kuard.example.com
              dnsNames:
              - www.kuard.example.com
    <!--NeedCopy-->
    

    Tras la validación correcta del nombre de dominio, el estado READY del certificado se establece en True.

  2. Compruebe que se haya emitido el certificado.

    % kubectl get certificate kuard-example-tls
    
       NAME           READY   SECRET              AGE
       -example-tls   True    kuard-example-tls   10m
    

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

    % kubectl describe certificates kuard-example-tls | tail -n 6

       Not After:               2020-04-04T13:34:23Z
       Events:
       Type    Reason     Age    From          Message
       ----    ------     ----   ----          -------
       Normal  Requested  11m    cert-manager  Created new CertificateRequest resource "kuard-example-tls-3030465986"
       Normal  Issued     7m21s  cert-manager  Certificate issued successfully
    

Verificar el certificado en Citrix ADC

Letsencrypt CA validó correctamente el dominio y emitió un nuevo certificado para el dominio. Se crea un secreto kubernetes.io/tls con el secretName especificado en el campo tls: de Ingress. Además, cert-manager inicia automáticamente una renovación, 30 días antes del vencimiento.

Para el desafío HTTP, cert-manager crea un recurso de Ingress temporal para redirigir el tráfico generado por la CA de Let’s Encrypt a los pods de cert-manager. En las validaciones correctas del dominio, se elimina este Ingress temporal.

  1. Compruebe que el secreto se ha creado mediante el siguiente comando:

    % kubectl get secret kuard-example-tls
    
    NAME                TYPE                DATA   AGE
    kuard-example-tls   kubernetes.io/tls   3      30m
    

    El Citrix Ingress Controller recoge el secreto y vincula el certificado al servidor virtual de conmutación de contenido en Citrix ADC CPX. Si hay certificados de CA intermedios, se vincula automáticamente al certificado del servidor y se presenta al cliente durante la negociación SSL.

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

    % kubectl exec -it cpx-ingress-55c88788fd-n2x9r bash -c cpx-ingress
    Defaulting container name to cpx-ingress.
    Use 'kubectl describe pod/cpx-ingress-55c88788fd-n2x9r -n default' to see all of the containers in this pod.
    
    % cli_script.sh 'sh ssl vs k8s-192.168.8.178_443_ssl'
    exec: sh ssl vs k8s-192.168.8.178_443_ssl
    
      Advanced SSL configuration for VServer k8s-192.168.8.178_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
      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
      HSTS Preload: NO
      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-GVWNYGVZKKRHKF7MZVTLOAEZYBS Server Certificate for SNI
    
    7) Cipher Name: DEFAULT
      Description: Default cipher list with encryption strength >= 128bit
    Done
    
    % cli_script.sh 'sh certkey'
    1) Name: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS
      Cert Path: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS.crt
      Key Path: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS.key
      Format: PEM
      Status: Valid,   Days to expiration:89
      Certificate Expiry Monitor: ENABLED
      Expiry Notification period: 30 days
      Certificate Type: "Client Certificate" "Server Certificate"
      Version: 3
      Serial Number: 03B2B57EA9E61A93F1D05EA3272FA95203C2
      Signature Algorithm: sha256WithRSAEncryption
      Issuer:  C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
      Validity
        Not Before: Jan  5 13:34:23 2020 GMT
        Not After : Apr  4 13:34:23 2020 GMT
      Subject:  CN=acme.cloudpst.net
      Public Key Algorithm: rsaEncryption
      Public Key size: 2048
      Ocsp Response Status: NONE
    2) Name: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS_ic1
      Cert Path: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS.crt_ic1
      Format: PEM
      Status: Valid,   Days to expiration:437
      Certificate Expiry Monitor: ENABLED
      Expiry Notification period: 30 days
      Certificate Type: "Intermediate CA"
      Version: 3
      Serial Number: 0A0141420000015385736A0B85ECA708
      Signature Algorithm: sha256WithRSAEncryption
      Issuer:  O=Digital Signature Trust Co.,CN=DST Root CA X3
      Validity
        Not Before: Mar 17 16:40:46 2016 GMT
        Not After : Mar 17 16:40:46 2021 GMT
      Subject:  C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
      Public Key Algorithm: rsaEncryption
      Public Key size: 2048
      Ocsp Response Status: NONE
    Done
    

El servidor web HTTPS ahora funciona con un certificado falso firmado por LE. El siguiente paso es pasar a producción con los certificados Let’s Encrypt reales.

Pasar a producción

Después de probar correctamente con Let’s Encrypt, puede obtener el certificado Let’s Encrypt real.

Debe cambiar el punto final de Let’s Encrypt de https:acme-staging-v02.api.letsencrypt.org/directory a https:acme-v02.api.letsencrypt.org/directory

A continuación, cambie el nombre del ClusterIssuer de letsencrypt-staging a letsencrypt-production


apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    # You must replace this email address with your own.
    # Let's Encrypt will use this to contact you about expiring
    # certificates, and issues related to your account.
    email: user@example.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # Secret resource used to store the account's private key.
      name: example-issuer-account-key
    # Add a single challenge solver, HTTP01 using citrix
    solvers:
    - http01:
        ingress:
          class: citrix
<!--NeedCopy-->

Nota:

Sustituya user@example.com por su dirección de correo electrónico.

Implemente el archivo con el siguiente comando:

% kubectl apply -f letsencrypt-prod.yaml

 clusterissuer "letsencrypt-prod" created

Ahora, repita el procedimiento de modificar la anotación en Ingress o crear un certificado CRD que desencadena la generación de un nuevo certificado.

Nota

Asegúrese de eliminar el secreto antiguo para que el administrador de certificados comience un nuevo desafío con la CA de producción.

% kubectl delete secret kuard-example-tls

 secret "kuard-example-tls" deleted

Una vez que el sitio web HTTP esté activo, puede redirigir el tráfico de HTTP a HTTPS mediante la anotación ingress.citrix.com/insecure-termination: redirect en el objeto de entrada.

Solución de problemas

Dado que la generación de certificados implica varios componentes, en esta sección se resumen las técnicas de solución de problemas que puede utilizar en caso de que se produzcan errores.

Verificar el estado de la generación de certificados

El objeto CRD de certificados define la gestión del ciclo de vida de la generación y renovación de certificados. Puede ver el estado del certificado mediante el comando kubectl describe de la siguiente manera.

% kubectl get certificate

NAME                READY   SECRET              AGE
kuard-example-tls   False   kuard-example-tls   9s

%  kubectl describe certificate kuard-example-tls

Status:
  Conditions:
    Last Transition Time:  2019-03-05T09:50:29Z
    Message:               Certificate does not exist
    Reason:                NotFound
    Status:                False
    Type:                  Ready
Events:
  Type    Reason        Age   From          Message
  ----    ------        ----  ----          -------
  Normal  OrderCreated  22s   cert-manager  Created Order resource "kuard-example-tls-1754626579"

También puede ver los principales eventos de certificados mediante el comando kubectl events:

kubectl get events

LAST SEEN   TYPE     REASON              KIND          MESSAGE
36s         Normal   Started             Challenge     Challenge scheduled for processing
36s         Normal   Created             Order         Created Challenge resource "kuard-example-tls-1754626579-0" for domain "acme.cloudpst.net"
38s         Normal   OrderCreated        Certificate   Created Order resource "kuard-example-tls-1754626579"
38s         Normal   CreateCertificate   Ingress       Successfully created Certificate "kuard-example-tls"

Analizar los registros de cert-manager

Si se produce un error, el primer paso es analizar los registros del componente cert-manager. Identifique el pod cert-manager mediante el siguiente comando:

% kubectl get po -n cert-manager

NAME                                    READY   STATUS      RESTARTS   AGE
cert-manager-76d48d47bf-5w4vx           1/1     Running     0          23h
cert-manager-webhook-67cfb86d56-6qtxr   1/1     Running     0          23h
cert-manager-webhook-ca-sync-x4q6f      0/1     Completed   4          23h

Aquí cert-manager-76d48d47bf-5w4vx es el pod principal de cert-manager, y los otros dos pods son pods de webhook de cert-manager.

Obtenga los registros del administrador de certificados mediante el siguiente comando:

% kubectl logs -f cert-manager-76d48d47bf-5w4vx -n cert-manager

Si se produce algún error al obtener el certificado, los registros ERROR proporcionan detalles sobre el error.

Consulta el secreto de Kubernetes

Usa el comando kubectl describe para verificar si tanto los certificados como la clave se completan en secreto de Kubernetes.

% kubectl describe secret kuard-example-tls

Name:         kuard-example-tls
Namespace:    default
Labels:       certmanager.k8s.io/certificate-name=kuard-example-tls
Annotations:  certmanager.k8s.io/alt-names: acme.cloudpst.net
              certmanager.k8s.io/common-name: acme.cloudpst.net
              certmanager.k8s.io/issuer-kind: ClusterIssuer
              certmanager.k8s.io/issuer-name: letsencrypt-staging

Type:  kubernetes.io/tls

Data
====
tls.crt:  3553 bytes
tls.key:  1679 bytes
ca.crt:   0 bytes

Si tls.crt y tls.key se rellenan en el secreto de Kubernetes, se ha completado la generación del certificado. Si solo tls.key está presente, la generación de certificados está incompleta. Analice los registros del administrador de certificados para obtener más detalles sobre el problema.

Analizar los registros del Citrix Ingress Controller

Si se genera y completa un secreto de Kubernetes, pero no se carga en Citrix ADC, puede analizar los registros desde el Citrix Ingress Controller mediante el siguiente comando.

% kubectl logs -f cpx-ingress-685c8bc976-zgz8q
Implemente la aplicación web HTTPS en Kubernetes con el Citrix Ingress Controller y Let`s Encrypt mediante cert-manager