Explorando los certificados SSL de Azure: nuestro viaje con Let's Encrypt

Al implementar un proyecto web, la implementación del certificado SSL es un desafío común al que probablemente se enfrenten todos los ingenieros, y yo no soy una excepción.

Por lo general, las nuevas empresas optan por certificados gratuitos como los de Let's Encrypt. Sin embargo, estos vienen con limitaciones e inconvenientes a considerar, los cuales se detallan en el sitio web del proveedor del certificado .

Echemos un vistazo más de cerca a los problemas que he encontrado personalmente con los certificados gratuitos:

• En primer lugar, requieren una reemisión regular y solo son válidos por un máximo de tres meses.
• En el caso de Kubernetes, los certificados deben almacenarse y regenerarse con frecuencia dentro de la plataforma.
• Los certificados wildcard y su renovación presentan una serie de dificultades.
• Los protocolos y algoritmos de cifrado también tienen sus propias peculiaridades.

Habiendo enfrentado estos problemas regularmente, he desarrollado una configuración de solución personalizada que utiliza certificados de Let's Encrypt. En este artículo, compartiré mis hallazgos y las lecciones que aprendí en el camino.

Recientemente, me he centrado en una pila de tecnología específica y me gustaría analizar una solución de infraestructura basada en clústeres de Kubernetes en el contexto de un proveedor de nube de Azure. Si bien cert-manager es una solución popular en este ámbito, prefiero instalarlo a través de Helm para mayor comodidad.

Entonces, sin más preámbulos, profundicemos en:

 helm repo add jetstack https: //charts.jetstack.io
helm repo update kubectl apply -f https: //github.com/jetstack/cert-manager/releases/download/v1.6.1/cert-manager.crds.yaml
helm install cert-manager jetstack/cert-manager -- namespace cert - manager -- create - namespace -- version v1 . 6 . 1

Después de eso, podemos crear un ClusterIssuer usando el siguiente archivo YAML:

 apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-cluster-issuer
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: p…[email protected]   #your e-mail
    privateKeySecretRef:
      name: letsencrypt-cluster-issuer
    solvers:
      - http01:
          ingress:
            class: nginx

En el futuro, hay dos opciones para implementar los certificados:

• Crear certificados agregando "tipo: Certificado";
  
• Gestión de certificados a través de su ingreso.

Exploremos ambas opciones.

En el primer escenario, mis archivos YAML se veían así:

 apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: myservice2  namespace : test
Spec :  duration : 2160h
  renewBefore : 72h
  dnsNames : - myservice2 . mydomain . org # you resources
  secretName : myservice2 - tls
  issuerRef :    name : letsencrypt - cluster - issuer
    kind : ClusterIssuer

Cabe señalar que solo se mencionó "secretName: myservice2-tls" en el ingreso en la sección TLS para un servicio en particular.

Por cierto, el archivo YAML contiene algunos parámetros útiles, como:

• duración: 48h – indicando la duración del certificado en horas
• renewBefore: 24h : especifica cuántas horas antes de que caduque el certificado, puede intentar renovar el certificado existente

Si se siente más cómodo trabajando con la consola, permítame ofrecerle una vista completa del certificado como ejemplo.

 kubectl describe certificates <cert name > -n <namespace name >

Entonces, ¿qué tenemos al final?

• Not After : la fecha de vencimiento del certificado;
• No antes : la fecha de creación del certificado (a menos que se especifique explícitamente en el campo Recurso YAML del certificado);
• Hora de renovación : la marca de tiempo antes de que caduque el certificado.

Personalmente, descubrí que administrar los certificados de Let's Encrypt a través de Ingress es más confiable y conveniente, razón por la cual lo he estado usando últimamente. Con este enfoque, además del nombre secreto y el nombre de host en la sección TLS, solo necesita especificar anotaciones en el archivo YAML de ingreso.

 annotations : cert-manager .io/cluster-issuer: "letsencrypt-cluster-issuer" cert-manager .io/renew-before: 72h

Y ahí lo tienes, ¡la magia de todo! Los certificados ahora se vuelven a emitir automáticamente, con un período de reserva de tres días antes de que caduquen en este ejemplo. Vale la pena señalar que, en el caso de Let's Encrypt, el período predeterminado es de 90 días.

Sin embargo, debido a las limitaciones de los certificados gratuitos de Let's Encrypt, nuestro equipo finalmente consideró la necesidad de un certificado integral que pudiera proteger no solo nuestro dominio sino también los subdominios. A medida que continuamos desarrollando nuestro proyecto en Azure, descubrimos que Azure Key Vault proporcionaba una ubicación conveniente para almacenar dichos certificados. Hemos estado usando la utilidad akv2k8s dentro de nuestro clúster de Kubernetes. Si te interesa, te animo a que conozcas más al respecto .

¿Qué es Azure Key Vault?

Una vez que haya obtenido un certificado en Azure, el siguiente paso es agregarlo a Azure Key Vault (AKV). Si bien este proceso es relativamente sencillo, verificar la propiedad del dominio puede ser un poco complicado. Sin embargo, una vez que todos los pasos de confirmación se completen con éxito, el certificado aparecerá en la sección "Secretos" del almacén de claves.

Uno de los principales beneficios de este enfoque es la renovación automática de certificados. El certificado se volverá a emitir y actualizar en AKV después de un año, y se sincronizará automáticamente con el Secreto en Kubernetes.

Para que el clúster de Kubernetes utilice el certificado adquirido, deberá otorgarle ciertos permisos y derechos de acceso.

Para hacer esto, primero deberá obtener el IdentityProfile.kubeletidentity.objectId del clúster. Puede hacerlo usando el siguiente comando:

 az aks show -g < RG > -n < AKS_name >

El grupo de recursos (RG) es la ubicación donde se almacena el clúster y AKS_name es el nombre de su clúster.

Después de obtener el IdentityProfile.kubeletidentity.objectId, debe copiarlo. A continuación, agregue el valor al comando para otorgar permisos de acceso a secretos:

 az keyvault set-policy --name < name AKV > --object-id < get from first step value > --secret-permissions get

A continuación, puede continuar con la instalación de akv2k8s, que se puede realizar a través de Helm u otros métodos preferidos, como se describe en la guía de instalación .

Siguiendo la documentación oficial , puede sincronizar su certificado de Azure Key Vault con Secret en un espacio de nombres de Kubernetes en particular. Aquí está mi archivo YAML:

 apiVersion: spv.no/v1 kind: AzureKeyVaultSecret metadata: name: wildcard-cert #any name  namespace : default
spec :  vault :    name : SandboxKeyVault # name you keyvault in Azure
    object :      name : name_object_id # name object id from Azure AKV this cert
      type : secret
  output :    secret :      name : wildcard - cert # any name for secret in your namespace
      type : kubernetes . io / tls
      chainOrder : ensureserverfirst # very important values !!!

Permítanme enfatizar la importancia de la última línea, ya que desempeñó un papel crucial en la resolución de un problema que encontré. Inicialmente, pude cargar el certificado en Kubernetes con éxito, pero no funcionó según lo previsto. Tomó algún tiempo diagnosticar el problema.

Resultó que, al exportar un certificado PFX desde Key Vault, el certificado del servidor a veces se coloca al final de la cadena en lugar de al principio, donde debería estar. Esto puede causar problemas cuando se usa con parámetros como ingress-nginx, ya que el certificado no se carga y vuelve a su valor original predeterminado. Sin embargo, al configurar chainOrder para asegurar el servidor primero, el certificado del servidor se coloca primero en la cadena.

Tras una inspección más cercana del certificado, descubrí que la cadena estaba dispuesta en la siguiente secuencia:

1. Intermedio
2. Raíz
3. Servidor

Habiendo discutido los aspectos técnicos y las configuraciones, volvamos a profundizar en las peculiaridades de los certificados de Azure.

Azure ofrece dos opciones para solicitar un certificado, ambas proporcionadas por GoDaddy:

• un certificado para un dominio o subdominio específico;
• un certificado comodín.

Optamos por este último, con la esperanza de que protegiera todas nuestras aplicaciones y servicios. Sin embargo, hubo algunos matices.

El certificado Azure Wildcard solo protege los subdominios de primer nivel. Por ejemplo, si tenemos un dominio llamado mydomain.com , el certificado solo cubrirá los subdominios de primer nivel en forma de .mydomain.com .

Por lo tanto, el certificado funcionará para recursos como service1.mydomain.com, service2.mydomain.com, service3.mydomain.com , pero no cubrirá service1.test.mydomain.com o mail.service1.mydomain.com .

¿Qué opciones tenemos entonces?

• Compra de certificados Wildcard separados para todos los subdominios necesarios;
• Adición de registros SAN ( Nombre alternativo del sujeto ) al certificado.

Es poco probable que la primera opción sea práctica, ya que la cantidad de subdominios, en particular los del segundo nivel, puede ser enorme. Por lo tanto, pagar un certificado wildcard para cada subdominio ( .service1.mydomain.com, *.dev.mydomain.com… ) no es la solución más razonable.

En cuanto a la segunda opción, tuve una larga conversación con el equipo de soporte de Azure sobre este asunto, pasé por todas las etapas de negación, frustración e ira, solo para darme cuenta al final de que la capacidad SAN para certificados aún no se ha implementado.

Justo hasta el final, esperaba que tal problema nunca ocurriera en Azure. Por el contrario, su competidor, AWS Amazon, ofrece certificados a través de AWS Certificate Manager (ACM) que admiten hasta 10 nombres de sujetos alternativos, incluidos los comodines. Te permite crear 10 subdominios con un carácter comodín (*), e incluso solicitar un aumento de cuota en AWS de hasta 100k.

Para concluir, compartiré cómo puede utilizar certificados con el servicio Front Door en Azure.

Descripción de Azure Front Door (AFD)

Para mí, Azure Front Door (AFD) es una puerta de enlace global y escalable que aprovecha la red perimetral mundial de Microsoft para dirigir el tráfico entrante a los puntos finales apropiados, que pueden ser aplicaciones o servicios web. Operando en la capa HTTP/HTTPS (capa 7), Front Door enruta las solicitudes de los clientes a un servidor de aplicaciones disponible desde el grupo. El lado del servidor de la aplicación puede ser cualquier servicio accesible por Internet, ya sea que esté alojado dentro o fuera de Azure.

Un ejemplo del sitio web de documentación https://docs.microsoft.com/ 

Azure Front Door es una herramienta conveniente que le permite equilibrar y representar el tráfico entrante que accede a aplicaciones y servicios distribuidos en todo el mundo. Ofrece una gama de características que incluyen la capacidad de vincular varias reglas configurando el controlador de reglas, las políticas de unión y la configuración del firewall. No profundizaré demasiado en los detalles del servicio AFD en este artículo, sino que me centraré en las peculiaridades del servicio de los certificados.

Como era de esperar, el tráfico entrante a Azure Front Door puede ser http o https . Si elige https , tiene tres opciones: generar un certificado en el propio servicio de Azure Front Door, cargar su propio certificado o sincronizar su certificado existente con Azure Key Vault. Para permitir que el servicio Front Door acceda a Key Vault, deberá configurar los permisos necesarios.

Recomiendo usar la última opción y seleccionar la última versión del certificado para evitar tener que renovarlo o regenerarlo manualmente. Al conectar el certificado de AKV, todo se mantendrá actualizado automáticamente.

Esta configuración le dará el siguiente resultado:

Esta es otra peculiaridad al dirigir el tráfico de Azure Front Door a AKS.

El manejo del tráfico http no es un problema, pero hay un detalle sutil que se debe tener en cuenta al configurar un grupo de recursos y especificar la dirección IP externa del clúster de AKS. Asegúrese de dejar en blanco el campo "Encabezado del nodo del componente del servidor" para asegurarse de que se complete automáticamente con los valores que se ingresaron en el campo "IP o nombre del nodo".

Suponga que tiene un certificado comodín de dominio adjunto a través de AKV que es utilizado por el servicio Front Door y descargado en el clúster de AKS a través de akv2k8s. El nombre de host de la interfaz (y el registro CNAME en DNS) para todas sus aplicaciones y servicios accesibles a través de Front Door será el siguiente:

• *.midominio.com: con el campo "encabezado del nodo del componente del servidor" en blanco;
• Su dirección IP de AKS externa tendrá una regla de redirección de http predeterminada a /.

Esto permitirá que todos los servicios en el formato *.mydomain.com funcionen correctamente. Una vez que haya completado esta configuración, estará listo.

En determinados escenarios, redirigir el tráfico de Azure Front Door a AKS a través de https puede ser más ventajoso. Para garantizar el correcto funcionamiento de Azure Front Door en la configuración del grupo de servidores, es crucial especificar un nombre de DNS correspondiente a su clúster de AKS , que está relacionado con SNI y comprobaciones de estado. De lo contrario, la configuración no funcionará.

En mi caso, no había ningún nombre asignado a mis clústeres de AKS, solo tenía servicios que antes funcionaban directamente pero tenían que funcionar a través de Azure Front Door. Para solucionar esto, tuve que crear un nombre de DNS independiente para el clúster de AKS, configurar DNS y configurar un servicio independiente con un certificado adjunto a la entrada. Solo entonces podría redirigir el tráfico https a los clústeres de AKS y asegurarme de que funciona correctamente para todos los servicios disponibles.

Es importante tener en cuenta las medidas de seguridad al configurar el permiso de conexión para AKS. Para garantizar una conexión segura, puede limitar el permiso para conectarse a AKS solo desde las direcciones IP de Azure Front Door en el grupo de seguridad de red para AKS (como se muestra en la imagen a continuación).

Además, puede configurar el ingreso de AKS para aceptar conexiones exclusivamente desde su encabezado de Azure Front Door por ID mediante el parámetro X-Azure-FDID .

Nota final y un consejo

1. Azure no proporciona información completa sobre las características y desventajas de sus certificados. Sin embargo, vale la pena mencionar que nos reembolsaron rápidamente el certificado comprado.

2. Durante nuestro proceso de desarrollo, continuamos usando Let's Encrypt. Aunque tiene sus limitaciones, no es la peor opción disponible.

3. Si su proyecto requiere varios subdominios con diferentes niveles de recursos, es posible que desee considerar los certificados "Comodín (también conocido como multidominio) con SAN" de proveedores externos. Estos certificados se pueden importar a Azure y utilizar todo su potencial.

4. Cuando se configura correctamente, Azure Front Door es un excelente servicio. Lo recomiendo altamente.

Escrito por Pavel Shapurau, ingeniero principal de DevOps, Social Discovery Group