Transport Layer Security (TLS)

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.

O privado CAs que você usa para políticas de cliente TLS deve ser usuário CAs root.

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 precisa ter as seguintes permissões do IAM:

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.

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:

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.

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.

É 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.

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.

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.

Opcionalmente, você pode especificar uma lista de nomes alternativos de assunto (SANs) nos quais confiar. SANs deve estar no formato FQDN ou URI. Se SANs forem fornecidos, o Envoy verifica se o nome alternativo do assunto do certificado apresentado corresponde a um dos nomes desta lista.

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

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