Transport Layer Security (TLS)

No App Mesh, o Transport Layer Security (TLS) criptografa a comunicação entre os proxies Envoy implantados em recursos computacionais que são representados no App Mesh por endpoints de malha, como e Nós virtuais e Gateways virtuais. O proxy negocia e encerra o TLS. Quando o proxy é implantado com um aplicação, o código do aplicação não é responsável por negociar uma sessão TLS. O proxy negocia o TLS em nome da sua aplicação.

O App Mesh permite que você forneça o certificado TLS ao proxy das seguintes formas:

• Um certificado privado do AWS Certificate Manager (ACM) emitido por um AWS Private Certificate Authority (AWS Private CA).

• Um certificado armazenado no sistema de arquivos local de um nó virtual emitido por sua própria autoridade de certificação (CA)

• Um certificado fornecido por um endpoint do Secrets Discovery Service (SDS) pelo soquete de domínio Unix local.

O Autorização do Envoy Proxy deve ser habilitado para o proxy Envoy implantado representado por um endpoint de malha. Recomendamos que, ao habilitar a autorização de proxy, restrinja o acesso somente ao endpoint de malha para o qual você está habilitando a criptografia.

Requisitos de certificado

Um dos nomes alternativos de assunto (SANs) no certificado deve corresponder a critérios específicos, dependendo de como o serviço real representado por um endpoint de malha é descoberto.

• DNS: um dos SANs do certificado deve corresponder ao valor fornecido nas configurações de descoberta de serviços DNS. Para uma aplicação com o nome de descoberta de serviços mesh-endpoint.apps.local, você pode criar um certificado correspondente a esse nome ou um certificado com o curinga *.apps.local.

• AWS Cloud Map— Uma das SANs certificadas deve corresponder ao valor fornecido nas configurações de descoberta do AWS Cloud Map serviço usando o formatoservice-name.namespace-name. Para um aplicativo com as configurações de descoberta de AWS Cloud Map serviço de ServiceName e mesh-endpoint apps.local NamespaceName, você pode criar um certificado que corresponda ao mesh-endpoint.apps.local nome ou um certificado com o caractere curinga. *.apps.local.

Para ambos os mecanismos de descoberta, se nenhum dos SANs do certificado corresponder às configurações de descoberta de serviços do DNS, a conexão entre os Envoys falhará com a mensagem de erro a seguir, conforme observado no Envoy do cliente.

TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

Certificados de autenticação TLS

O App Mesh oferece suporte a várias fontes de certificados ao usar a autenticação TLS.

AWS Private CA

O certificado deve ser armazenado no ACM na mesma região e conta da AWS do endpoint de malha que usará o certificado. O certificado da CA não precisa estar na mesma AWS conta, mas ainda precisa estar na mesma região do endpoint de malha. Se você não tiver um CA privada da AWS, deverá criar um antes de solicitar um certificado dele. Para obter mais informações sobre como solicitar um certificado de um existente AWS Private CA usando o ACM, consulte Solicitar um certificado privado. O certificado não pode ser público.

As CAs privadas que você usa para políticas de cliente TLS devem ser CAs de usuário raiz.

Para configurar um nó virtual com certificados e CAs de AWS Private CA, o principal (como um usuário ou uma função) que você usa para chamar o App Mesh deve ter as seguintes permissões do IAM:

• Para qualquer certificado que você adiciona à configuração TLS de um receptor, a entidade principal deve ter a permissão acm:DescribeCertificate.

• Para todas as CAs configuradas em uma política de cliente TLS, a entidade principal deve ter a permissão acm-pca:DescribeCertificateAuthority.

Importante

Compartilhar CAs com outras contas pode dar a essas contas privilégios não intencionais à CA. Recomendamos o uso de políticas baseadas em recursos para restringir o acesso a apenas acm-pca:DescribeCertificateAuthority e acm-pca:GetCertificateAuthorityCertificate para contas que não precisam emitir certificados da CA.

Você pode adicionar essas permissões à uma política do IAM existente que está anexada a uma entidade principal ou criar uma nova entidade principal e uma nova política e anexar a política à entidade principal. Para obter mais informações, consulte Edição de políticas do IAM, criação de políticas do IAM e adição de permissões de identidade do IAM.

nota

Você paga uma taxa mensal pela operação de cada um AWS Private CA até excluí-lo. Você paga também pelos certificados privados que emite a cada mês e pelos certificados privados que exporta. Para obter mais informações, consulte Preços do AWS Certificate Manager.

Ao ativar a autorização de proxy para o Envoy Proxy que um endpoint de malha representa, o perfil do IAM que você usa deve receber as seguintes permissões do IAM:

• Para qualquer certificado configurado no receptor de um nó virtual, a função deve ter a permissão acm:ExportCertificate.

• Para todas as CAs configuradas em uma política de cliente TLS, a função deve ter a permissãoacm-pca:GetCertificateAuthorityCertificate.

Sistema de arquivos

Você pode distribuir certificados para o Envoy usando o sistema de arquivos. É possível fazer isso disponibilizando a cadeia de certificados e a chave privada correspondente disponível no caminho do arquivo. Dessa forma, esses recursos podem ser acessados pelo proxy do Envoy sidecar.

Envoy’s Secret Discovery Service (SDS)

O Envoy busca segredos, como certificados TLS, de um endpoint específico por meio do protocolo Secrets Discovery. Para obter mais informações sobre esse protocolo, consulte a documentação do SDS do Envoy.

O App Mesh configura o proxy Envoy para usar um soquete de domínio Unix Local ao proxy como o endpoint do Secret Discovery Service (SDS) quando o SDS é usado como a fonte para seus certificados e cadeias de certificados. Você pode configurar o caminho para esse endpoint usando a variável de ambiente APPMESH_SDS_SOCKET_PATH.

Importante

O Secrets Discovery Service local usando o soquete de domínio Unix é compatível com o proxy App Mesh Envoy versão 1.15.1.0 e posterior.

O App Mesh oferece suporte ao protocolo V2 SDS usando gRPC.

Integração com o SPIFFE Runtime Environment (SPIRE)

É possível usar qualquer implementação secundária da API do SDS, incluindo cadeias de ferramentas existentes, como o SPIFFE Runtime Environment (SPIRE). O SPIRE foi projetado para permitir a implantação da autenticação de TLS mútuo entre várias workloads em sistemas distribuídos. Ele atesta a identidade das workloads em tempo de execução. O SPIRE também fornece chaves e certificados específicos para workloads, de curta duração e com rotação automática diretamente para workloads.

Você deve configurar o atendente SPIRE como um provedor de SDS para o Envoy. Permita que ele forneça diretamente ao Envoy o material essencial necessário para fornecer autenticação de TLS mútuo. Execute agentes SPIRE em sidecars próximos aos proxies Envoy. O atendente se encarrega de regenerar as chaves e certificados de curta duração, conforme necessário. O atendente atesta o Envoy e determina quais identidades de serviço e certificados de CA devem ser disponibilizados ao Envoy quando o Envoy se conecta ao servidor SDS exposto pelo agente SPIRE.

Durante esse processo, as identidades de serviço e os certificados CA são alternados e as atualizações são transmitidas de volta ao Envoy. O Envoy as aplica imediatamente às novas conexões sem interrupções ou tempo de inatividade e sem que as chaves privadas cheguem ao sistema de arquivos.

Como o App Mesh configura os Envoys para negociar o TLS

O App Mesh usa a configuração do endpoint de malha do cliente e do servidor ao determinar como configurar a comunicação entre os Envoys em uma malha.

Com as políticas do cliente

Quando uma política de cliente impõe o uso do TLS e uma das portas na política do cliente corresponde à porta da política do servidor, a política do cliente é usada para configurar o contexto de validação do TLS do cliente. Por exemplo, se a política de cliente de um gateway virtual corresponder à política de servidor de um nó virtual, a negociação de TLS será tentada entre os proxies usando as configurações definidas na política de cliente do gateway virtual. Se a política do cliente não corresponder à porta da política do servidor, o TLS entre os proxies poderá ou não ser negociado, dependendo das configurações de TLS da política do servidor.

Sem políticas de cliente

Se o cliente não tiver configurado uma política de cliente ou se a política do cliente não corresponder à porta do servidor, o App Mesh usará o servidor para determinar se deve ou não negociar o TLS do cliente e como. Por exemplo, se um gateway virtual não tiver especificado uma política de cliente e um nó virtual não tiver configurado o encerramento do TLS, o TLS não será negociado entre os proxies. Se um cliente não tiver especificado uma política de cliente correspondente e um servidor tiver sido configurado com os modos TLS STRICT ou PERMISSIVE, os proxies serão configurados para negociar o TLS. Dependendo de como os certificados foram fornecidos para o encerramento do TLS, o seguinte comportamento adicional se aplica.

• Certificados TLS gerenciados pelo ACM: quando um servidor configura o encerramento do TLS usando um certificado gerenciado pelo ACM, o App Mesh configura automaticamente os clientes para negociar o TLS e validar o certificado em relação à CA do usuário raiz ao qual o certificado está vinculado.

• Certificados TLS baseados em arquivos: quando um servidor configura o encerramento do TLS usando um certificado do sistema de arquivos local do proxy, o App Mesh configura automaticamente um cliente para negociar o TLS, mas o certificado do servidor não é validado.

Nomes alternativos do assunto

Você pode opcionalmente especificar uma Subject Alternative Names (SANs) nos quais confiar. Os SANs devem estar no formato FQDN ou URI. Se os SANs forem fornecidos, o Envoy verifica se o Nome alternativo do assunto do certificado apresentado corresponde a um dos nomes dessa lista.

Se você não especificar SANs no endpoint da malha de encerramento, o proxy Envoy para esse nó não verificará a SAN em um certificado de cliente do mesmo nível. Se você não especificar SANs no endpoint da malha de origem, a SAN no certificado fornecido pelo endpoint de encerramento deverá corresponder à configuração de descoberta do serviço de endpoints da malha.

Para obter mais informações, consulte App Mesh TLS: requisitos de certificado.

Importante

Você só pode usar SANs curinga se a política do cliente para TLS estiver definida como not enforced. Se a política de cliente para o nó virtual ou gateway virtual do cliente estiver configurada para aplicar o TLS, ela não poderá aceitar um SAN curinga.

Verifique a criptografia

Depois de habilitar o TLS, você pode consultar o proxy Envoy para confirmar se a comunicação está criptografada. O proxy Envoy emite estatísticas sobre recursos que podem ajudá-lo a entender se sua comunicação TLS está trabalhando corretamente. Por exemplo, o proxy Envoy registra estatísticas sobre o número de handshakes TLS bem-sucedidos que ele negociou para um endpoint de malha especificado. Determine quantos handshakes TLS bem-sucedidos ocorreram para um endpoint de malha nomeado my-mesh-endpoint com o comando a seguir.

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

Na saída retornada do exemplo a seguir, houve três handshakes para o endpoint de malha, portanto, a comunicação é criptografada.

listener.0.0.0.0_15000.ssl.handshake: 3

O proxy Envoy também emite estatísticas quando a negociação do TLS está falhando. Determine se houve erros de TLS no endpoint da malha.

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

Na saída retornada do exemplo, não houve nenhum erro em várias estatísticas, então a negociação do TLS foi bem-sucedida.

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 obter mais informações sobre as estatísticas do Envoy TLS, consulte Estatísticas do receptor Envoy.

Renovação de certificado

AWS Private CA

Quando você renova um certificado com o ACM, o certificado renovado será distribuído automaticamente aos seus proxies conectados dentro de 35 minutos após a conclusão da renovação. Recomendamos usar a renovação gerenciada para renovar automaticamente os certificados perto do final do período de validade. Para obter mais informações, consulte Renovação gerenciada para certificados emitidos pela Amazon do ACM no Guia do AWS Certificate Manager usuário.

Seu próprio certificado

Ao usar um certificado do sistema de arquivos local, o Envoy não recarregará automaticamente o certificado quando ele for alterado. Você pode reiniciar ou reimplantar o processo Envoy para carregar um novo certificado. É possível também colocar um certificado mais novo em um caminho de arquivo diferente e atualizar a configuração do nó virtual ou do gateway com esse caminho de arquivo.

Configure as cargas de trabalho do Amazon ECS para usar a autenticação TLS com AWS App Mesh

Você pode configurar sua malha para usar a autenticação TLS. Certifique-se de que os certificados estejam disponíveis para os sidecars do proxy do Envoy que você adiciona aos workloads. Você pode anexar um volume EBS ou EFS ao seu sidecar do Envoy ou pode armazenar e recuperar certificados do AWS Secrets Manager.

• Se você estiver usando distribuição de certificados baseada em arquivos, conecte um volume do EBS ou do EFS ao seu sidecar do Envoy. Certifique-se de que o caminho para o certificado e a chave privada corresponda ao que está configurado em AWS App Mesh.

• Se você estiver usando a distribuição baseada em SDS, adicione um sidecar que implemente a API SDS do Envoy com acesso ao certificado.

nota

O SPIRE não é compatível com o Amazon ECS.

Configure as cargas de trabalho do Kubernetes para usar a autenticação TLS com AWS App Mesh

Você pode configurar o AWS App Mesh Controller for Kubernetes para habilitar a autenticação TLS para back-ends e ouvintes do serviço de nó virtual e gateway virtual. Certifique-se de que os certificados estejam disponíveis para os sidecars do proxy do Envoy que você adiciona aos workloads. É possível ver um exemplo para cada tipo de distribuição na seção passo a passo da Mutual TLS Authentication.

• Se você estiver usando distribuição de certificados baseada em arquivos, conecte um volume do EBS ou do EFS ao seu sidecar do Envoy. Certifique-se de que o caminho para o certificado e a chave privada corresponda ao configurado no controlador. Como alternativa, é possível usar um Kubernetes Secret montado no sistema de arquivos.

• Se estiver usando a distribuição baseada em SDS, deverá configurar um provedor de SDS local de nó que implemente a API SDS do Envoy. O Envoy chegará até lá via UDS. Para habilitar o suporte a mTLS baseado em SDS no AppMesh controlador EKS, defina o enable-sds sinalizador como true e forneça o caminho UDS do provedor de SDS local para o controlador por meio do sinalizador. sds-uds-path Se usa o Helm, configure-os como parte da instalação do seu controlador:

  --set sds.enabled=true

nota

Não é possível usar o SPIRE para distribuir seus certificados se estiver usando o Amazon Elastic Kubernetes Service (Amazon EKS) no modo Fargate.