seguridad de la capa de transporte (TLS)

En App Mesh, la seguridad de la capa de transporte (TLS) cifra la comunicación entre los proxies de Envoy implementados en los recursos informáticos que están representados en App Mesh por puntos de conexión de malla como Nodos virtuales y Puertas de enlace virtuales. El proxy negocia y finaliza la TLS. Cuando el proxy se implementa con una aplicación, el código de la aplicación no es responsable de negociar una sesión de TLS. El proxy negocia la TLS en nombre de su aplicación.

App Mesh permite proporcionar el certificado TLS al proxy de las siguientes maneras:

• Un certificado privado de AWS Certificate Manager (ACM) emitido por una AWS Private Certificate Authority (AWS Private CA).

• Un certificado almacenado en el sistema de archivos local de un nodo virtual emitido por su propia autoridad de certificación (CA)

• Un certificado proporcionado por un punto de conexión SDS (Secrets Discovery Service) a través de un socket de dominio Unix local.

La Autorización de proxy de Envoy debe estar habilitada para el proxy de Envoy implementado representado por un punto de conexión de malla. Le recomendamos que, al habilitar la autorización del proxy, restrinja el acceso únicamente al punto de conexión de malla para el que esté habilitando el cifrado.

Requisitos del certificado

Uno de los Nombres alternativos del asunto (SAN) del certificado debe cumplir unos criterios específicos, en función de cómo se detecte el servicio real representado por un punto de conexión de malla.

• DNS: uno de los SAN del certificado debe coincidir con el valor proporcionado en la configuración de detección de servicios del DNS. Para una aplicación con el nombre de detección de servicios de mesh-endpoint.apps.local, puede crear un certificado que coincida con ese nombre o un certificado con el comodín *.apps.local.

• AWS Cloud Map— Una de las SAN certificadas debe coincidir con el valor proporcionado en la configuración de detección de AWS Cloud Map servicios mediante el formatoservice-name.namespace-name. Para una aplicación con la AWS Cloud Map configuración de detección de servicios de ServiceName y mesh-endpoint apps.local NamespaceName, puede crear un certificado que coincida con el mesh-endpoint.apps.local nombre o un certificado con el comodín. *.apps.local.

En ambos mecanismos de detección, si ninguno de los SAN con certificados coincide con la configuración de detección de servicios del DNS, se produce un error en la conexión entre los Envoys y aparece el siguiente mensaje de error, tal y como lo muestra el cliente de Envoy.

TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

Certificados de autenticación TLS

App Mesh admite varios orígenes para los certificados cuando se utiliza la autenticación TLS.

AWS Private CA

El certificado se debe almacenar en ACM en la misma región y cuenta de AWS que el punto de conexión de malla que utilizará el certificado. No es necesario que el certificado de la CA esté en la misma AWS cuenta, pero sí en la misma región que el punto final de malla. Si no tiene una Autoridad de certificación privada de AWS, debe crear una antes de poder solicitarle un certificado. Para obtener más información sobre cómo solicitar un certificado a una empresa existente que AWS Private CA utiliza ACM, consulte Solicitar un certificado privado. El certificado no puede ser un certificado público.

Las autoridades de certificación privadas que utilice para las políticas de cliente de TLS deben ser autoridades de certificación de usuario raíz.

Para configurar un nodo virtual con certificados y CA de AWS Private CA, el principal (por ejemplo, un usuario o un rol) que utilices para llamar a App Mesh debe tener los siguientes permisos de IAM:

• Para cualquier certificado que añada a la configuración de TLS de un oyente, la entidad principal debe tener el permiso acm:DescribeCertificate.

• Para cualquier autoridad de certificación configurada en una política de cliente de TLS, la entidad principal debe tener el permiso acm-pca:DescribeCertificateAuthority.

importante

Al compartir las autoridades de certificación con otras cuentas, es posible que esas cuentas obtengan privilegios no deseados para la autoridad de certificación. Recomendamos utilizar políticas basadas en los recursos para restringir el acceso únicamente a acm-pca:DescribeCertificateAuthority y acm-pca:GetCertificateAuthorityCertificate para las cuentas que no necesiten emitir certificados de la autoridad de certificación.

Puede añadir estos permisos a una política de IAM existente que esté asociada a una entidad principal o crear una entidad principal y una política nuevas y asociar la política a la entidad principal. Para obtener más información, consulte Edición de políticas de IAM, Creación de políticas de IAM y Adición de permisos de identidad de IAM.

nota

Pagas una cuota mensual por el funcionamiento de cada uno de ellos AWS Private CA hasta que los elimines. También paga por los certificados privados que emita cada mes y por los certificados privados que exporte. Para más información, consulte Precios de AWS Certificate Manager.

Al habilitar la autorización de proxy para el proxy de Envoy que representa un punto de conexión de malla, se deben asignar los siguientes permisos de IAM al rol de IAM que utilice:

• Para cualquier certificado configurado en el oyente de un nodo virtual, el rol debe tener el permiso acm:ExportCertificate.

• Para cualquier autoridad de certificación configurada en una política de cliente de TLS, el rol debe tener el permiso acm-pca:GetCertificateAuthorityCertificate.

Sistema de archivos

Puede distribuir los certificados a Envoy mediante el sistema de archivos. Para ello, haga que la cadena de certificados y la clave privada correspondiente estén disponibles en la ruta del archivo. De esta forma, se puede obtener acceso a estos recursos a través del proxy sidecar de Envoy.

Secret Discovery Service (SDS) de Envoy

Envoy obtiene secretos, por ejemplo, los certificados TLS, de un punto de conexión específico a través del protocolo Secrets Discovery. Para obtener más información sobre este protocolo, consulte la documentación de SDS de Envoy.

App Mesh configura el proxy de Envoy para que utilice un socket de dominio de Unix local en el proxy para que sirva como punto de conexión de Secret Discovery Service (SDS) cuando SDS sirva de origen para sus certificados y cadenas de certificados. Puede configurar la ruta a este punto de conexión mediante la variable de entorno APPMESH_SDS_SOCKET_PATH.

importante

El protocolo Secrets Discovery Service local que utiliza el socket de dominio de Unix es compatible con el proxy de App Mesh Envoy versión 1.15.1.0 y versiones posteriores.

App Mesh es compatible con el protocolo SDS V2 mediante gRPC.

Integración con el entorno en tiempo de ejecución de SPIFFE (SPIRE)

Puede utilizar cualquier implementación sidecar de la API de SDS, incluidas las cadenas de herramientas existentes, por ejemplo, el entorno en tiempo de ejecución de SPIFFE (SPIRE). SPIRE está diseñado para permitir la implementación de la autenticación TLS mutua entre varias cargas de trabajo en sistemas distribuidos. Acredita la identidad de las cargas de trabajo en tiempo de ejecución. SPIRE también ofrece claves y certificados específicos de la carga de trabajo, de corta duración y que rotan automáticamente directamente a las cargas de trabajo.

Debe configurar el agente de SPIRE como proveedor de SDS para Envoy. Permita que suministre directamente a Envoy el material clave que necesita para proporcionar una autenticación TLS mutua. Ejecute los agentes de SPIRE en sidecars junto a los proxies de Envoy. El agente se encarga de volver a generar las claves y certificados de corta duración según sea necesario. El agente acredita a Envoy y determina qué identidades del servicio y certificados de la autoridad de certificación debe poner a disposición de Envoy cuando este se conecte al servidor de SDS expuesto por el agente de SPIRE.

Durante este proceso, las identidades del servicio y los certificados de la autoridad de certificación se rotan y las actualizaciones se transmiten a Envoy. Envoy los aplica inmediatamente a las nuevas conexiones sin interrupciones ni tiempos de inactividad y sin que las claves privadas entren en contacto con el sistema de archivos.

Cómo App Mesh configura Envoys para negociar TLS

App Mesh utiliza la configuración de punto de conexión de malla tanto del cliente como del servidor para determinar cómo configurar la comunicación entre los Envoys en una malla.

Con políticas de cliente

Cuando una política de cliente exige el uso de TLS y uno de los puertos de la política de cliente coincide con el puerto de la política de servidor, la política de cliente se utiliza para configurar el contexto de validación de TLS del cliente. Por ejemplo, si la política de cliente de una puerta de enlace virtual coincide con la política de servidor de un nodo virtual, se intentará negociar TLS entre los proxies utilizando la configuración definida en la política de cliente de la puerta de enlace virtual. Si la política de cliente no coincide con el puerto de la política de servidor, la seguridad TLS entre los proxies puede negociarse o no, según la configuración de TLS de la política de servidor.

Sin políticas de cliente

Si el cliente no ha configurado una política de cliente o la política de cliente no coincide con el puerto del servidor, App Mesh utilizará el servidor para determinar si se debe negociar o no la seguridad TLS con el cliente y cómo hacerlo. Por ejemplo, si una puerta de enlace virtual no ha especificado una política de cliente y un nodo virtual no ha configurado la terminación de TLS, la seguridad TLS no se negociará entre los proxies. Si un cliente no ha especificado una política de cliente coincidente y se ha configurado un servidor con los modos STRICT o PERMISSIVE de TLS, los proxies se configurarán para negociar la seguridad TLS. En función de cómo se hayan proporcionado los certificados para la terminación de TLS, se aplicará el siguiente comportamiento adicional.

• Certificados TLS administrados por ACM: cuando un servidor ha configurado la terminación de TLS mediante un certificado administrado por ACM, App Mesh configura automáticamente los clientes para negociar TLS y validar el certificado con la autoridad de certificación del usuario raíz a la que se encadena el certificado.

• Certificados TLS basados en archivos: cuando un servidor ha configurado la terminación de TLS mediante un certificado del sistema de archivos local del proxy, App Mesh configura automáticamente un cliente para negociar TLS, pero el certificado del servidor no se valida.

Nombres alternativos de asunto

Si lo desea, puede especificar una lista de nombres alternativos de asunto (SAN) en los que pueda confiar. Los SAN deben estar en formato FQDN o URI. Si se proporcionan SAN, Envoy verifica que el nombre alternativo del sujeto del certificado presentado coincida con uno de los nombres de esta lista.

Si no especifica nombres SAN en el punto de conexión de malla de terminación, el proxy de Envoy de ese nodo no verifica el SAN en un certificado de cliente del mismo nivel. Si no especifica nombres SAN en el punto de conexión de malla de origen, el SAN en el certificado proporcionado por el punto de conexión de terminación debe coincidir con la configuración de detección de servicios del punto de conexión de malla.

Para obtener más información, consulte App Mesh TLS: requisitos del certificado.

importante

Solo puede usar nombres SAN comodín si la política de cliente para TLS está establecida en not enforced. Si la política de cliente del nodo virtual o la puerta de enlace virtual del cliente está configurada para aplicar TLS, no podrá aceptar un SAN comodín.

Verificar el cifrado

Una vez que haya activado TLS, puede consultar el proxy de Envoy para confirmar que la comunicación está cifrada. El proxy de Envoy emite estadísticas sobre los recursos que pueden ayudarlo a saber si su comunicación TLS funciona correctamente. Por ejemplo, el proxy de Envoy registra estadísticas sobre el número de protocolos de enlace TLS que ha negociado satisfactoriamente para un punto de conexión de malla específico. Determine cuántos protocolos de enlace de manos TLS satisfactorios hubo para un punto de conexión de malla denominado my-mesh-endpoint mediante el siguiente comando.

curl -s 'http://my-mesh-endpoint.apps.local:9901/stats' | grep ssl.handshake

En el resultado que devolvió el siguiente ejemplo, había tres protocolos de enlace para el punto de conexión de malla, por lo que la comunicación está cifrada.

listener.0.0.0.0_15000.ssl.handshake: 3

El proxy de Envoy también emite estadísticas cuando la negociación de TLS fracasa. Determine si hubo errores de TLS en el punto de conexión de malla.

curl -s 'http://my-mesh-endpoint.apps.local:9901/stats' | grep -e "ssl.*\(fail\|error\)"

En el resultado que devolvió el ejemplo, no hubo errores en varias estadísticas, por lo que la negociación de TLS se realizó correctamente.

listener.0.0.0.0_15000.ssl.connection_error: 0
listener.0.0.0.0_15000.ssl.fail_verify_cert_hash: 0
listener.0.0.0.0_15000.ssl.fail_verify_error: 0
listener.0.0.0.0_15000.ssl.fail_verify_no_cert: 0
listener.0.0.0.0_15000.ssl.ssl.fail_verify_san: 0

Para obtener más información sobre las estadísticas de TLS de Envoy, consulte Estadísticas del oyente de Envoy.

Renovación de certificados

AWS Private CA

Al renovar un certificado con ACM, el certificado renovado se distribuirá automáticamente a los proxies conectados en un plazo de 35 minutos a partir de la finalización de la renovación. Recomendamos utilizar la renovación administrada para renovar automáticamente los certificados cuando se acerque el final de su período de validez. Para obtener más información, consulte Renovación gestionada de los certificados de ACM emitidos por Amazon en la Guía del AWS Certificate Manager usuario.

Su propio certificado

Al utilizar un certificado del sistema de archivos local, Envoy no volverá a cargar automáticamente el certificado cuando se modifique. Puede reiniciar o volver a implementar el proceso de Envoy para cargar un certificado nuevo. También puede colocar un certificado más reciente en una ruta de archivo diferente y actualizar la configuración del nodo virtual o la puerta de enlace con esa ruta de archivo.

Configure las cargas de trabajo de Amazon ECS para usar la autenticación TLS con AWS App Mesh

Puede configurar su malla para que utilice la autenticación TLS. Asegúrese de que los certificados estén disponibles para los sidecars proxy de Envoy que añada a sus cargas de trabajo. Puede asociar un volumen de EBS o EFS a su sidecar de Envoy, o puede almacenar y recuperar certificados de AWS Secrets Manager.

• Si utiliza la distribución de certificados basada en archivos, asocie un volumen de EBS o EFS a su sidecar de Envoy. Asegúrese de que la ruta al certificado y la clave privada coincidan con la que están configurados. AWS App Mesh

• Si utiliza una distribución basada en SDS, añada un sidecar que implemente la API SDS de Envoy con acceso al certificado.

nota

Amazon ECS no admite SPIRE.

Configure las cargas de trabajo de Kubernetes para usar la autenticación TLS con AWS App Mesh

Puede configurar el AWS App Mesh Controller para Kubernetes para habilitar la autenticación TLS para los backends y los oyentes del servicio de nodo virtual y puerta de enlace virtual. Asegúrese de que los certificados estén disponibles para los sidecars del proxy de Envoy que añada a sus cargas de trabajo. Puede ver un ejemplo de cada tipo de distribución en la sección tutorial de Autenticación TLS mutua.

• Si utiliza la distribución de certificados basada en archivos, asocie un volumen de EBS o EFS a su sidecar de Envoy. Asegúrese de que la ruta al certificado y a la clave privada coincidan con la ruta configurada en el controlador. Como alternativa, puede usar un Kubernetes Secret que esté montado en el sistema de archivos.

• Si utiliza una distribución basada en SDS, debe configurar un proveedor SDS local de nodo que implemente la API SDS de Envoy. Envoy conectará con él a través de UDS. Para habilitar la compatibilidad con los mTLS basados en SDS en el AppMesh controlador EKS, defina el enable-sds indicador en true y proporcione la ruta UDS del proveedor de SDS local al controlador mediante el indicador. sds-uds-path Si utiliza helm, debe configurarlos como parte de la instalación del controlador:

  --set sds.enabled=true

nota

No podrá utilizar SPIRE para distribuir sus certificados si usa Amazon Elastic Kubernetes Service (Amazon EKS) en modo Fargate.