Al implementar un proyecto web, la implementación   es un desafío común al que probablemente se enfrenten todos los ingenieros, y yo no soy una excepción. del certificado SSL  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   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. de Kubernetes     Entonces, sin más preámbulos, profundicemos en:     helm repo update                          helm repo add jetstack https: //charts.jetstack.io 
 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….@gmail.com     #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í:    kind: Certificate metadata: name: myservice2                                                       apiVersion: cert-manager.io/v1    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:    – indicando la duración del certificado en horas duración: 48h    : especifica cuántas horas antes de que caduque el certificado, puede intentar renovar el certificado existente renewBefore: 24h  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?    : la fecha de vencimiento del certificado; Not After    : la fecha de creación del certificado (a menos que se especifique explícitamente en el campo Recurso YAML del certificado); No antes    : la marca de tiempo antes de que caduque el certificado. Hora de renovación  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   , puede sincronizar su certificado de Azure Key Vault con Secret en un espacio de nombres de Kubernetes en particular. Aquí está mi archivo YAML:  la documentación oficial    kind: AzureKeyVaultSecret metadata: name: wildcard-cert #any name                                                             apiVersion: spv.no/v1    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:  Intermedio  Raíz  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   , el certificado solo cubrirá los subdominios de primer nivel en forma de   . mydomain.com .mydomain.com  Por lo tanto, el certificado funcionará para recursos como   , pero no cubrirá   o   . service1.mydomain.com, service2.mydomain.com, service3.mydomain.com service1.test.mydomain.com mail.service1.mydomain.com  ¿Qué opciones tenemos entonces?  Compra de certificados Wildcard separados para todos los subdominios necesarios;  Adición de registros SAN       al certificado. ( Nombre alternativo del sujeto )  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 (   ) no es la solución más razonable. .service1.mydomain.com, *.dev.mydomain.com…  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   de la aplicación puede ser cualquier servicio accesible por Internet, ya sea que esté alojado dentro o fuera de Azure.  lado del servidor     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   o   . Si elige   , 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. http https https  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   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".  http  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   funcionen correctamente. Una vez que haya completado esta configuración, estará listo.  *.mydomain.com  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   , que está relacionado con SNI y comprobaciones de estado. De lo contrario, la configuración no funcionará. un nombre de DNS correspondiente a su clúster de AKS  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   a los clústeres de AKS y asegurarme de que funciona correctamente para todos los servicios disponibles. https  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

See how we create Social Life 3.0 👉

Social Discovery Group Earns the Great Place To Work® Certification in the USA!

Swipe Away Loneliness: 2024 Dating Trends Forecast

Este audio es producido en el idioma original de la historia!

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

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Telegram: el puente de Crypto Island hacia el continente

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Telegram: el puente de Crypto Island hacia el continente

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps