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
, puede crear un certificado que coincida con ese nombre o un certificado con el comodínmesh-endpoint.apps.local
*.
.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 formato
. En el caso de una aplicación con una configuración de detección de AWS Cloud Map serviceNameservice-name.namespace-name
servicios igual o igual a namespaceNamemesh-endpoint
, puede crear un certificado que coincida con el nombreapps.local
o un certificado con el carácter comodínmesh-endpoint.apps.local
*.
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
yacm-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
con el siguiente comando.my-mesh-endpoint
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 entrue
y proporcione la UDS ruta del SDS proveedor local al controlador a través delsds-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.