Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Configure el end-to-end cifrado para aplicaciones en Amazon EKS mediante cert-manager y Let's Encrypt *Mahendra Revanasiddappa y Vasanth Jeyaraj, Amazon Web Services* ## Resumen La implementación del end-to-end cifrado puede resultar compleja y necesita administrar los certificados de cada activo de su arquitectura de microservicios. Si bien puede finalizar la conexión de Transport Layer Security (TLS) en el extremo de la red de Amazon Web Services (AWS) con un Network Load Balancer o Amazon API Gateway, algunas organizaciones end-to-end requieren el cifrado. Este patrón utiliza el controlador de entrada NGINX para la entrada. Esto se debe a que cuando se crea una entrada de Kubernetes, el recurso de entrada utiliza un equilibrador de carga de red. El equilibrador de carga de red no permite cargar certificados de cliente. Por lo tanto, no puede lograr el TLS mutuo con el ingreso de Kubernetes. Este patrón está pensado para las organizaciones que requieren la autenticación mutua entre todos los microservicios de sus aplicaciones. El TLS mutuo reduce la carga que supone mantener los nombres de usuario o las contraseñas y, además, puede utilizar un marco de seguridad listo para usar. El enfoque de este patrón es compatible si su organización tiene una gran cantidad de dispositivos conectados o si debe cumplir con estrictas pautas de seguridad. Este patrón ayuda a aumentar la postura de seguridad de su organización al implementar el end-to-end cifrado para las aplicaciones que se ejecutan en Amazon Elastic Kubernetes Service (Amazon EKS). Este patrón proporciona una aplicación y un código de muestra en el repositorio de GitHub [End-to-end cifrado de Amazon EKS](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme) para mostrar cómo se ejecuta un microservicio con el end-to-end cifrado en Amazon EKS. El enfoque del patrón utiliza [cert-manager](https://cert-manager.io/docs/), un complemento de Kubernetes, con [Let's Encrypt](https://letsencrypt.org/) como autoridad de certificación (CA). Let's Encrypt es una solución rentable para administrar certificados y proporciona certificados gratuitos con una validez de 90 días. Cert-Manager automatiza el aprovisionamiento bajo demanda y la rotación de los certificados cuando se implementa un nuevo microservicio en Amazon EKS.  **Destinatarios previstos** Este patrón se recomienda para los usuarios que tengan experiencia con Kubernetes, TLS, Amazon Route 53 y el Sistema de nombres de dominio (DNS). ## Requisitos previos y limitaciones **Requisitos previos** + Una cuenta de AWS activa. + Un clúster existente de Amazon EKS. + Interfaz de la línea de comandos de AWS (AWS CLI) versión 1.7, instalada y configurada en macOS, Linux o Windows + La utilidad de línea de comandos `kubectl`, instalada y configurada para acceder al clúster de Amazon EKS. Para obtener más información, consulte [Installing kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) (Instalación de kubectl) en la documentación de Amazon EKS. + Un nombre DNS existente para probar una aplicación. Para obtener más información, consulte [Registrar nombres de dominio mediante Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar.html) en la documentación de Amazon Route 53.  + La última versión de [Helm](https://docs.aws.amazon.com/eks/latest/userguide/helm.html), instalada en su máquina local. Para obtener más información al respecto, consulte [Uso de Helm con Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html) en la documentación de Amazon EKS y en el repositorio de GitHub [Helm](https://github.com/helm/helm).  + El GitHub [End-to-end cifrado del repositorio EKS de Amazon](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme), clonado en su máquina local.  + Sustituya los siguientes valores en los `trustpolicy.json` archivos `policy.json` y del repositorio de GitHub [End-to-end cifrado clonado en Amazon EKS](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme): + ``: sustitúyalo por el ID de cuenta de AWS de la cuenta en la que desea implementar la solución.  + ``: sustitúyalo por el ID de zona de Route 53 del nombre de dominio.  + ``: sustitúyalo por el nombre de la función de AWS Identity and Access Management del rol de IAM asociada a los nodos de Amazon EKS. + ``: sustitúyalo por el espacio de nombres de Kubernetes en el que se despliega el controlador de entrada NGINX y la aplicación de ejemplo. + ``: sustitúyalo por el nombre de dominio DNS de Route 53 **Limitaciones** + Este patrón no describe cómo rotar los certificados y solo muestra cómo usar los certificados con microservicios en Amazon EKS.  ## Arquitectura En el siguiente diagrama se muestran los componentes de la arquitectura y el flujo de trabajo de esta aplicación. ![\[Flujo de trabajo para configurar el cifrado para las aplicaciones en Amazon EKS mediante cert-manager y Let's Encrypt.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/patterns/images/pattern-img/9aa3ee9e-73db-41f5-a467-b5c47fef496e/images/40692ede-6fb3-474e-8c9e-85c51529e8ad.png) En el diagrama, se muestra el siguiente flujo de trabajo: 1. Un cliente envía una solicitud de acceso a la aplicación al nombre DNS. 1. El registro de Route 53 es un CNAME para el equilibrador de carga de red. 1. El equilibrador de carga de red reenvía la solicitud al controlador de entrada NGINX que está configurado con un agente oyente TLS. La comunicación entre el controlador de entrada NGINX y el equilibrador de carga de red sigue el protocolo HTTPS. 1. El controlador de entrada NGINX realiza un enrutamiento basado en rutas en función de la solicitud del cliente al servicio de la aplicación. 1. El servicio de aplicaciones reenvía la solicitud al pod de la aplicación. La aplicación está diseñada para utilizar el mismo certificado al llamar a secretos. 1. Los pods ejecutan la aplicación de ejemplo con los certificados del administrador de certificados. La comunicación entre el controlador de entrada de NGINX y los pods utiliza HTTPS. | | | Nota: Cert-Manager se ejecuta en su propio espacio de nombres. Utiliza un rol de clúster de Kubernetes para aprovisionar certificados como secretos en espacios de nombres específicos. Puede adjuntar esos espacios de nombres a los pods de aplicaciones y al NGINX Ingress Controller. | | --- | ## Tools (Herramientas) **Servicios de AWS** + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) es un servicio administrado que puede utilizar para ejecutar Kubernetes en AWS sin necesidad de instalar, operar ni mantener su propio plano de control o nodos de Kubernetes. + [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) distribuye automáticamente el tráfico entrante entre varios destinos, por ejemplo, instancias EC2, contenedores y direcciones IP en una o varias zonas de disponibilidad. + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) le permite administrar de forma segura el acceso a los recursos de AWS mediante el control de quién está autenticado y autorizado a utilizarlos. + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) es un servicio web de sistema de nombres de dominio (DNS) escalable y de alta disponibilidad. **Otras herramientas** + [cert-manager](https://cert-manager.io/docs/installation/supported-releases/) es un complemento de Kubernetes que solicita certificados, los distribuye a los contenedores de Kubernetes y automatiza la renovación de los certificados. + [NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx/) es una solución de gestión del tráfico para aplicaciones nativas en la nube en Kubernetes y entornos contenerizados. ## Epics ### Cree y configure una zona alojada pública con Route 53 | Tarea | Descripción | Habilidades requeridas | | --- | --- | --- | | Cree una zona alojada pública para Route 53. | Inicie sesión en la consola de administración de AWS, abra la consola Amazon Route 53, elija **Zonas alojadas** y, a continuación, elija **Crear zona alojada**. Cree una zona alojada pública y registre el ID de la zona. Para obtener más información, consulte [Crear una zona alojada pública](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingHostedZone.html) en la documentación de Amazon Route 53.ACME DNS01 utiliza el proveedor de DNS para solicitar al administrador de certificados que emita el certificado. Este desafío le pide que demuestre que controla el DNS de su nombre de dominio poniendo un valor específico en un registro TXT situado debajo de ese nombre de dominio. Cuando Let's Encrypt proporciona un token a su cliente ACME, este crea un registro TXT derivado de ese token y de su clave de cuenta, y coloca ese registro en `_acme-challenge.`. Luego, Let's Encrypt consulta el DNS de ese registro. Si encuentra una coincidencia, puede proceder a emitir un certificado. | AWS DevOps | ### Configure un rol de IAM para permitir que el administrador de certificados acceda a la zona alojada pública | Tarea | Descripción | Habilidades requeridas | | --- | --- | --- | | Cree la política de IAM para cert-manager. | Se requiere una política de IAM para proporcionar a cert-manager permiso para validar que usted es propietario del dominio de Route 53. El `policy.json` ejemplo de política de IAM se proporciona en el `1-IAMRole` directorio del repositorio de GitHub [End-to-end cifrado clonado de Amazon EKS](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme).Escriba el siguiente comando en la CLI de AWS para crear la política de IAM:
aws iam create-policy \
  --policy-name PolicyForCertManager \
  --policy-document file://policy.json
| AWS DevOps | | Cree el rol de IAM para cert-manager. | Después de crear la política de IAM, debe crear un rol de IAM. El ejemplo del rol de IAM `trustpolicy.json` se proporciona en el directorio `1-IAMRole`.Escriba el siguiente comando en la CLI de AWS para crear el rol de IAM:
aws iam create-role \
  --role-name RoleForCertManager \
  --assume-role-policy-document file://trustpolicy.json
| AWS DevOps | | Asocie la política de al rol. | Escriba el siguiente comando en la CLI de AWS para adjuntar la política de IAM al rol de IAM: Sustituya `AWS_ACCOUNT_ID` por el ID de la cuenta de AWS. 
aws iam attach-role-policy \
  --policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/PolicyForCertManager \
  --role-name RoleForCertManager
| AWS DevOps | ### Configure el controlador de entrada NGINX en Amazon EKS | Tarea | Descripción | Habilidades requeridas | | --- | --- | --- | | Implemente el controlador de entrada NGINX. | Instale la versión más reciente de `nginx-ingress` mediante Helm. Puede modificar la configuración `nginx-ingress` según sus requisitos antes de implementarla. Este patrón utiliza un equilibrador de carga de red anotado e interno que está disponible en el directorio `5-Nginx-Ingress-Controller`. Instale el controlador de entrada NGINX ejecutando el siguiente comando Helm desde el directorio `5-Nginx-Ingress-Controller`.`helm install test-nginx nginx-stable/nginx-ingress  -f  5-Nginx-Ingress-Controller/values_internal_nlb.yaml` | AWS DevOps | | Verifique que el controlador de entrada NGINX se encuentre instalado. | Escriba el comando `helm list`. El resultado debería mostrar que el controlador de entrada NGINX está instalado. | AWS DevOps | | Cree un registro A de Route 53. | El registro A apunta al equilibrador de carga de red creado por el controlador de entrada de NGINX.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps | ### Configurar NGINX en VirtualServer Amazon EKS | Tarea | Descripción | Habilidades requeridas | | --- | --- | --- | | Implemente NGINX. VirtualServer | El VirtualServer recurso NGINX es una configuración de equilibrio de carga que es una alternativa al recurso de entrada. La configuración para crear el VirtualServer recurso NGINX está disponible en el archivo del `nginx_virtualserver.yaml` directorio. `6-Nginx-Virtual-Server` Introduzca el siguiente comando `kubectl` para crear el recurso VirtualServer NGINX.`kubectl apply -f  nginx_virtualserver.yaml`Asegúrese de actualizar el nombre de dominio de la aplicación, el secreto del certificado y el nombre del servicio de la aplicación en el archivo `nginx_virtualserver.yaml`. | AWS DevOps | | Compruebe que se ha creado NGINX VirtualServer . | Introduzca el siguiente comando `kubectl` para comprobar que el VirtualServer recurso NGINX se creó correctamente.`kubectl get virtualserver`Compruebe que la columna `Host` coincida con el nombre de dominio de su aplicación. | AWS DevOps | | Implemente el servidor web NGINX con TLS habilitado. | Este patrón utiliza un servidor web NGINX con TLS habilitado como aplicación para probar el cifrado. end-to-end Los archivos de configuración necesarios para implementar la aplicación de prueba están disponibles en el directorio `demo-webserver`. Para implementar la aplicación de prueba, ejecute el siguiente comando en `kubectl`:`kubectl apply -f nginx-tls-ap.yaml` | AWS DevOps | | Compruebe que se hayan creado los recursos de la aplicación de prueba. | Introduzca los siguientes comandos en `kubectl` para comprobar que se han creado los recursos necesarios para la aplicación de prueba:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps | | Validación de la solicitud. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps | ## Recursos relacionados **Recursos de AWS** + [Creación de registros con la consola de Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html) (documentación de Amazon Route 53) + [Uso de un equilibrador de carga de red con el controlador de entrada de NGINX en Amazon EKS](https://aws.amazon.com/blogs/opensource/network-load-balancer-nginx-ingress-controller-eks/) en el blog de AWS **Otros recursos** + [Route 53](https://cert-manager.io/docs/configuration/acme/dns01/route53/) (documentación del administrador de certificados) + [Configuración del proveedor de desafíos DNS01](https://cert-manager.io/docs/configuration/acme/dns01/) (documentación sobre el administrador de certificados) + [El desafío Let's Encrypt DNS](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) (documentación de Let's Encrypt)