Segurança da camada de transporte (TLS)

O certificado deve ser armazenado ACM na mesma região e AWS conta 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. Para obter mais informações sobre como solicitar um certificado de um usuário existente AWS Private CA ACM, consulte Solicitar um certificado privado. O certificado não pode ser público.

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

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 IAM permissões:

Você pode adicionar essas permissões a uma IAM política existente anexada a um diretor ou criar um novo diretor e uma nova política e anexar a política ao principal. Para obter mais informações, consulte Edição de IAM políticas, criação de IAM políticas e adição de permissões de IAM identidade.

Quando você habilita a autorização de proxy para o Envoy Proxy que um endpoint de malha representa, a IAM função que você usa deve receber as seguintes permissões: 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 TLS certificados, 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 Envoy.

O App Mesh configura o proxy Envoy para usar um soquete de domínio Unix que é local para o proxy para servir como endpoint do Secret Discovery Service (SDS) quando SDS serve como 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.

Você pode usar qualquer implementação secundária do SDSAPI, incluindo cadeias de ferramentas existentes, como SPIFFERuntime Environment (). SPIRE SPIREfoi projetado para permitir a implantação da TLS autenticação mútua entre várias cargas de trabalho em sistemas distribuídos. Ele atesta a identidade das workloads em tempo de execução. SPIREtambém fornece chaves e certificados específicos para cargas de trabalho, de curta duração e com rotação automática diretamente para cargas de trabalho.

Você deve configurar o SPIRE Agente como SDS provedor do Envoy. Permita que ele forneça diretamente ao Envoy o material essencial necessário para fornecer autenticação mútuaTLS. Execute SPIRE agentes em sidecars próximos aos proxies do Envoy. O atendente se encarrega de regenerar as chaves e certificados de curta duração, conforme necessário. O Agente 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 exposto pelo Agente. SDS 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 deTLS, e uma das portas na política de cliente corresponde à porta da política do servidor, a política de cliente é usada para configurar o contexto de TLS validação do cliente. Por exemplo, se a política de cliente de um gateway virtual corresponder à política de servidor de um nó virtual, haverá uma tentativa de TLS negociação 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, a negociação TLS entre os proxies pode ou não ser negociada, dependendo das configurações da política do servidor. TLS

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 TLS com o 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 a TLS terminação, TLS isso 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 TLS modos STRICT ouPERMISSIVE, os proxies serão configurados para negociar. TLS Dependendo de como os certificados foram fornecidos para TLS rescisão, o seguinte comportamento adicional se aplica.

Opcionalmente, você pode especificar uma lista de nomes alternativos de assunto (SANs) nos quais confiar. SANsdeve estar no URI formato FQDN ou. 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 de malha de terminação, o proxy Envoy desse nó não o verificará SAN em um certificado de cliente de mesmo nível. Se você não especificar SANs no endpoint de malha de origem, o SAN 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.