Seleccione sus preferencias de cookies

Usamos cookies esenciales y herramientas similares que son necesarias para proporcionar nuestro sitio y nuestros servicios. Usamos cookies de rendimiento para recopilar estadísticas anónimas para que podamos entender cómo los clientes usan nuestro sitio y hacer mejoras. Las cookies esenciales no se pueden desactivar, pero puede hacer clic en “Personalizar” o “Rechazar” para rechazar las cookies de rendimiento.

Si está de acuerdo, AWS y los terceros aprobados también utilizarán cookies para proporcionar características útiles del sitio, recordar sus preferencias y mostrar contenido relevante, incluida publicidad relevante. Para aceptar o rechazar todas las cookies no esenciales, haga clic en “Aceptar” o “Rechazar”. Para elegir opciones más detalladas, haga clic en “Personalizar”.

Seguridad de la capa de transporte (TLS) - AWS App Mesh

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.

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.

Seguridad de la capa de transporte (TLS)

importante

Aviso de fin del soporte: el 30 de septiembre de 2026, AWS dejaremos de ofrecer soporte para AWS App Mesh. Después del 30 de septiembre de 2026, ya no podrás acceder a la AWS App Mesh consola ni a AWS App Mesh los recursos. Para obtener más información, visita esta entrada de blog Migración desde AWS App Mesh a Amazon ECS Service Connect.

En App Mesh, Transport Layer Security (TLS) cifra la comunicación entre los proxies de Envoy desplegados en los recursos informáticos que están representados en App Mesh mediante puntos finales de malla, como y. Nodos virtuales Puertas de enlace virtuales El proxy negocia y finaliza. TLS Cuando el proxy se implementa con una aplicación, el código de la aplicación no es responsable de negociar una TLS sesión. El apoderado negocia TLS en nombre de su solicitud.

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

  • Un certificado privado de AWS Certificate Manager (ACM) emitido por un 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 final del Secrets Discovery Service (SDS) a través de un conector 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 (SANs) del certificado debe cumplir criterios específicos, en función de cómo se descubra el servicio real representado por un punto final de malla.

  • DNS— Uno de los certificados SANs debe coincidir con el valor proporcionado en la configuración DNS de detección de servicios. 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— Uno de los certificados SANs debe coincidir con el valor proporcionado en la configuración AWS Cloud Map de detección de servicios utilizando el formatoservice-name.namespace-name. En el caso de una aplicación con una configuración de detección de AWS Cloud Map serviceName mesh-endpoint servicios igual o igual a namespaceName apps.local, puede crear un certificado que coincida con el nombre mesh-endpoint.apps.local o un certificado con el carácter comodín *.apps.local.

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

TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

TLScertificados de autenticación

App Mesh admite varias fuentes de certificados cuando se utiliza la TLS autenticación.

AWS Private CA

El certificado debe almacenarse ACM en la misma región y AWS cuenta que el punto final 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 un AWS Private CA usuario existenteACM, consulte Solicitar un certificado privado. El certificado no puede ser un certificado público.

El usuario privado CAs que utilice para las políticas del TLS cliente debe ser el usuario rootCAs.

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

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

  • Para cualquier política CAs configurada en un TLS cliente, el principal debe tener el acm-pca:DescribeCertificateAuthority permiso.

importante

Si se comparte CAs con otras cuentas, es posible que esas cuentas obtengan privilegios no deseados para la CA. 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 agregar estos permisos a una IAM política existente que esté asociada a un director o crear un director y una política nuevos y adjuntar la política al director. Para obtener más información, consulte Edición de IAM políticas, Creación de IAM políticas y Adición de permisos de IAM identidad.

nota

Pagas una cuota mensual por el funcionamiento de cada una de ellas AWS Private CA hasta que las 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.

Cuando habilitas la autorización de proxy para el proxy de Envoy que representa un punto de conexión en malla, debes asignar los siguientes IAM permisos a la IAM función que utilices:

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

  • Para cualquier política CAs configurada en un TLS cliente, la función debe tener el acm-pca:GetCertificateAuthorityCertificate permiso.

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.

Servicio de Descubrimiento Secreto de Envoy (SDS)

Envoy obtiene datos secretos, como TLS certificados, de un punto final específico mediante el protocolo Secrets Discovery. Para obtener más información sobre este protocolo, consulte la SDSdocumentación de Envoy.

App Mesh configura el proxy de Envoy para que utilice un socket de dominio de Unix que es local para el proxy y que sirva como punto final del Secret Discovery Service (SDS) cuando SDS sirva de fuente 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 admite el SDS protocolo V2 usando gRPC.

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

Puede utilizar cualquier implementación paralela del SDSAPI, incluidas las cadenas de herramientas existentes, como SPIFFERuntime Environment () SPIRE. SPIREestá diseñado para permitir el despliegue de la TLS autenticación mutua entre múltiples cargas de trabajo en sistemas distribuidos. Acredita la identidad de las cargas de trabajo en tiempo de ejecución. SPIREtambién ofrece claves y certificados específicos para cada carga de trabajo, de corta duración y que giran automáticamente directamente a las cargas de trabajo.

Debe configurar el SPIRE agente como proveedor de Envoy. SDS Permita que suministre directamente a Envoy el material clave que necesita para garantizar la TLS autenticación mutua. Dirige a SPIRE los agentes en un sidecar 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 certifica a Envoy y determina qué identidades de servicio y certificados de CA debe poner a disposición de Envoy cuando Envoy se conecte al SDS servidor expuesto por el agente. 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 configura App Mesh a 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 la política del TLS servidor y uno de los puertos de la política del cliente coincide con el puerto de la política del servidor, la política del cliente se utiliza para configurar el contexto de TLS validación 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á TLS negociar 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 del servidor, es posible que se negocie o no TLS entre los proxies, según la configuración de la política del TLS 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 negociar TLS o no 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 TLS terminación, no se TLS negociará entre los servidores proxy. Si un cliente no ha especificado una política de cliente coincidente y se ha configurado un servidor con TLS modos STRICT oPERMISSIVE, los proxies se configurarán para negociar. TLS En función de cómo se hayan proporcionado los certificados para la TLS rescisión, se aplicará el siguiente comportamiento adicional.

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

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

Nombres alternativos de asunto

Si lo desea, puede especificar una lista de nombres alternativos de sujetos (SANs) en los que pueda confiar. SANsdebe tener el URI formato FQDN o. Si SANs se proporcionan, Envoy verificará que el nombre alternativo del sujeto del certificado presentado coincida con uno de los nombres de esta lista.

Si no especificas SANs el punto final de malla, el proxy de Envoy para ese nodo no verificará el SAN certificado de un cliente homólogo. Si no lo especificas SANs en el punto final de malla de origen, SAN el certificado proporcionado por el punto final debe coincidir con la configuración de detección del servicio de punto final de malla.

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

importante

Solo puede usar un comodín SANs si la política de cliente 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 TLS aplicarse, no podrá aceptar un comodínSAN.

Verificación del cifrado

Una vez que lo hayas activadoTLS, puedes 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 ayudarte a saber si tu TLS comunicación funciona correctamente. Por ejemplo, el proxy de Envoy registra estadísticas sobre el número de TLS apretones de manos exitosos que ha negociado para un punto final de malla específico. Determine cuántos TLS apretones de manos satisfactorios hubo para un punto final de malla denominado my-mesh-endpoint con 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 TLS negociación fracasa. Determine si hubo TLS errores en el punto final de la malla.

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

En el ejemplo devuelto, no hubo errores en varias estadísticas, por lo que la TLS negociación 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 TLS las estadísticas de Envoy, consulte Estadísticas de Envoy Listener.

Renovación de certificados

AWS Private CA

Al renovar un certificado conACM, el certificado renovado se distribuirá automáticamente a los servidores proxy 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, consulta Renovación gestionada ACM de los certificados 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 ECS las cargas de trabajo de Amazon para usar la TLS autenticación con AWS App Mesh

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

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

  • Si utilizas la distribución SDS basada en bases, añade un sidecar que implemente el de Envoy SDS API con acceso al certificado.

nota

SPIREno es compatible con AmazonECS.

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

Puede configurar el AWS App Mesh Controller para Kubernetes para permitir la TLS autenticación de 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. Puedes ver un ejemplo de cada tipo de distribución en la sección de tutoriales de Autenticación mutua. TLS

  • Si utiliza la distribución de certificados basada en archivos, adjunte un EFS volumen EBS o 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 utilizas la distribución SDS basada en nodos, deberías configurar un SDS proveedor local de nodos que implemente el de Envoy. SDS API Envoy lo alcanzaráUDS. Para habilitar el TLS soporte SDS basado en m en el EKS AppMesh controlador, defina el enable-sds indicador en true y proporcione la UDS ruta del SDS proveedor local al controlador a través del sds-uds-path indicador. 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 utiliza Amazon Elastic Kubernetes Service (Amazon) en modo FargateEKS.

PrivacidadTérminos del sitioPreferencias de cookies
© 2024, Amazon Web Services, Inc o sus afiliados. Todos los derechos reservados.