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

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

Demasiado Largo; Para Leer

Developers: Build Less. Deliver More. [Learn how]	

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

Demasiado Largo; Para Leer

Social Discovery Group

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

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

Demasiado Largo; Para Leer

Social Discovery Group

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

HISTORIAS RELACIONADAS