Compartir a través de


Uso de los certificados de Let's Encrypt en Application Gateway para clústeres de AKS

Puede configurar la instancia de Azure Kubernetes Service (AKS) para usar Let's Encrypt y obtener automáticamente un certificado TLS/SSL para su dominio. El certificado se instala en Azure Application Gateway, que realiza la terminación TLS/SSL para el clúster de AKS.

La configuración que se describe en este artículo usa el complemento cert-manager de Kubernetes, que automatiza la creación y administración de certificados.

Sugerencia

Considere Puerta de enlace de aplicaciones para contenedores como solución de entrada de Kubernetes.

Instalación del complemento

Siga estos pasos para instalar cert-manager en el clúster de AKS existente:

  1. Ejecute el siguiente script para instalar el gráfico de Helm de cert-manager. Este script realiza las acciones siguientes:

    • Crea un nuevo espacio de nombres de cert-manager en el clúster de AKS
    • Crea las siguientes definiciones de recursos personalizados (CRD): Certificate, Challenge, ClusterIssuer, Issuer, Order
    • Instala el gráfico de cert-manager (desde el sitio de cert-manager)
    #!/bin/bash
    
    # Install the CustomResourceDefinition resources separately
    kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.16.1/cert-manager.crds.yaml
    
    # Create the namespace for cert-manager
    kubectl create namespace cert-manager
    
    # Label the cert-manager namespace to disable resource validation
    kubectl label namespace cert-manager cert-manager.io/disable-validation=true
    
    # Add the Jetstack Helm repository
    helm repo add jetstack https://charts.jetstack.io
    
    # Update your local Helm chart repository cache
    helm repo update
    
    # Install the cert-manager Helm chart
    # Helm v3+
    helm install \
      cert-manager jetstack/cert-manager \
      --namespace cert-manager \
      --version v1.16.1 \
      # --set installCRDs=true
    
    # To automatically install and manage the CRDs as part of your Helm release,
    # you must add the --set installCRDs=true flag to your Helm installation command.
    
  2. Cree un recurso ClusterIssuer. Cert-manager necesita este recurso para representar la entidad de certificación Let's Encrypt que emite el certificado firmado.

    Cert-manager usa el recurso ClusterIssuer sin espacio de nombres para emitir certificados que se pueden consumir desde varios espacios de nombres. Let's Encrypt usa el protocolo ACME para comprobar que controla un nombre de dominio determinado y para emitir un certificado. Puede obtener más detalles sobre cómo configurar las propiedades ClusterIssuer en la documentación de cert-manager.

    ClusterIssuer ordena a cert-manager que emita certificados mediante el entorno de ensayo de Let's Encrypt que se usa para las pruebas. (El certificado raíz no está presente en los almacenes de confianza del explorador o cliente).

    El tipo de desafío predeterminado del siguiente código YAML es http01. Puede encontrar otros tipos de desafíos en la documentación de Let's Encrypt.

    En el siguiente YAML, asegúrese de reemplazar <YOUR.EMAIL@ADDRESS> con su información.

    #!/bin/bash
    kubectl apply -f - <<EOF
    apiVersion: cert-manager.io/v1
    kind: ClusterIssuer
    metadata:
      name: letsencrypt-staging
    spec:
      acme:
        # You must replace this email address with your own.
        # Let's Encrypt uses this to contact you about expiring
        # certificates, and issues related to your account.
        email: <YOUR.EMAIL@ADDRESS>
        # ACME server URL for Let's Encrypt's staging environment.
        # The staging environment won't issue trusted certificates but is
        # used to ensure that the verification process is working properly
        # before moving to production
        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
        # Enable the HTTP-01 challenge provider
        # you prove ownership of a domain by ensuring that a particular
        # file is present at the domain
        solvers:
          - http01:
            ingress:
             #   class: azure/application-gateway
               ingressTemplate:
                 metadata:
                   annotations:
                     kubernetes.io/ingress.class: azure/application-gateway
    EOF
    
  3. Cree un recurso de entrada para exponer la aplicación guestbook mediante la implementación de Application Gateway con el certificado de Let's Encrypt.

    Asegúrese de que la implementación de Application Gateway tiene una configuración de IP de front-end pública con un nombre DNS. Use el dominio predeterminado azure.com, o aprovisione una zona de Azure DNS y luego asigne su propio dominio personalizado. La anotación certmanager.k8s.io/cluster-issuer: letsencrypt-staging le indica a cert-manager que procese el recurso de entrada etiquetado.

    En el siguiente YAML, asegúrese de reemplazar <PLACEHOLDERS.COM> por su propio dominio o por el dominio de Application Gateway (por ejemplo, kh-aks-ingress.westeurope.cloudapp.azure.com).

    kubectl apply -f - <<EOF
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: guestbook-letsencrypt-staging
      annotations:
        kubernetes.io/ingress.class: azure/application-gateway
        cert-manager.io/cluster-issuer: letsencrypt-staging
    spec:
      tls:
      - hosts:
        - <PLACEHOLDERS.COM>
        secretName: guestbook-secret-name
      rules:
      - host: <PLACEHOLDERS.COM>
          http:
          paths:
          - backend:
              serviceName: frontend
              servicePort: 80
    EOF
    

    Después de unos segundos, puede acceder al servicio de guestbook con la dirección URL HTTPS de Application Gateway mediante el certificado de Let's Encrypt para el almacenamiento provisional emitido automáticamente.

    Es posible que su explorador le advierta de una entidad de certificación no válida. El motivo es que CN=Fake LE Intermediate X1 emitió el certificado de almacenamiento provisional. Esta advertencia significa que el sistema funcionó según lo esperado y está listo para el certificado de producción.

  4. Después de que haya configurado correctamente el certificado de almacenamiento provisional, puede cambiar a un servidor ACME de producción:

    1. Reemplace la anotación de almacenamiento provisional en el recurso de entrada con cert-manager.io/cluster-issuer: letsencrypt-prod.
    2. Elimine el recurso de almacenamiento provisional existente de ClusterIssuer que creó anteriormente. Cree un nuevo recurso de almacenamiento provisional reemplazando el servidor ACME del YAML del ClusterIssuer anterior por https://acme-v02.api.letsencrypt.org/directory.

Antes de que expire el certificado de Let's Encrypt, cert-manager lo actualiza automáticamente en el almacén de secretos de Kubernetes. En ese punto, el controlador de entrada de Application Gateway aplica el secreto actualizado al que se hace referencia en los recursos de entrada que está usando para configurar la instancia de Application Gateway.