Configurar métodos de autenticação de cluster no Lambda
O Lambda precisa de permissão para acessar o cluster do Amazon MSK, recuperar registros e realizar outras tarefas. O Amazon MSK é compatível com vários métodos de autenticação com o cluster do MSK.
Métodos de autenticação de cluster
Acesso não autenticado
Se nenhum cliente acessar o cluster pela Internet, você poderá usar o acesso não autenticado.
Autenticação SASL/SCRAM
O Lambda é compatível com autenticação Simple Authentication and Security Layer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM), com a função de hash SHA-512 e com a criptografia de Transport Layer Security (TLS). Para que o Lambda se conecte ao cluster, armazene as credenciais de autenticação (nome de usuário e senha) em um segredo do Secrets Manager e referencie esse segredo quando configurar o mapeamento da origem do evento.
Para obter mais informações sobre o uso do Secrets Manager, consulte Sign-in credentials authentication with Secrets Manager no Amazon Managed Streaming for Apache Kafka Developer Guide.
nota
O Amazon MSK não é compatível com a autenticação SASL/PLAIN.
Autenticação TLS mútua
O Mutual TLS (mTLS) fornece autenticação bidirecional entre o cliente e o servidor. O cliente envia um certificado ao servidor para que o servidor verifique o cliente. O servidor também envia um certificado para o cliente para que ele verifique o servidor.
Para integrações do Amazon MSK com o Lambda, o cluster do MSK atua como servidor e o Lambda atua como cliente.
-
Para que o Lambda verifique o cluster do MSK, você configura um certificado de cliente como um segredo no Secrets Manager e referencia esse certificado na configuração do mapeamento da origem do evento. O certificado do cliente deve ser assinado por uma autoridade de certificação (CA) no armazenamento de confiança do servidor.
-
O cluster do MSK também envia um certificado de servidor ao Lambda. O certificado do servidor deve ser assinado por uma autoridade de certificação (CA) no armazenamento de confiança da AWS.
O Amazon MSK não é compatível com certificados de servidor auto-assinados. Todos os agentes no Amazon MSK usam certificados públicos assinados por CAs do Amazon Trust Services
O segredo CLIENT_CERTIFICATE_TLS_AUTH requer um campo de certificado e um campo de chave privada. Para uma chave privada criptografada, o segredo requer uma senha de chave privada. Tanto o certificado como a chave privada devem estar no formato PEM.
nota
O Lambda oferece suporte a algoritmos de criptografia de chave privada PBES1
O campo certificate (certificado) deve conter uma lista de certificados, começando pelo certificado do cliente, seguido por quaisquer certificados intermediários e terminando com o certificado raiz. Cada certificado deve iniciar em uma nova linha com a seguinte estrutura:
-----BEGIN CERTIFICATE----- <certificate contents> -----END CERTIFICATE-----
O Secrets Manager oferece suporte a segredos de até 65.536 bytes, que é espaço suficiente para cadeias de certificados longas.
A chave privada deve estar no formato PKCS #8
-----BEGIN PRIVATE KEY----- <private key contents> -----END PRIVATE KEY-----
Para uma chave privada criptografada, use a seguinte estrutura:
-----BEGIN ENCRYPTED PRIVATE KEY----- <private key contents> -----END ENCRYPTED PRIVATE KEY-----
O exemplo a seguir exibe o conteúdo de um segredo para autenticação mTLS usando uma chave privada criptografada. Para uma chave privada criptografada, inclua a senha da chave privada no segredo.
{ "privateKeyPassword": "testpassword", "certificate": "-----BEGIN CERTIFICATE----- MIIE5DCCAsygAwIBAgIRAPJdwaFaNRrytHBto0j5BA0wDQYJKoZIhvcNAQELBQAw ... j0Lh4/+1HfgyE2KlmII36dg4IMzNjAFEBZiCRoPimO40s1cRqtFHXoal0QQbIlxk cmUuiAii9R0= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFgjCCA2qgAwIBAgIQdjNZd6uFf9hbNC5RdfmHrzANBgkqhkiG9w0BAQsFADBb ... rQoiowbbk5wXCheYSANQIfTZ6weQTgiCHCCbuuMKNVS95FkXm0vqVD/YpXKwA/no c8PH3PSoAaRwMMgOSA2ALJvbRz8mpg== -----END CERTIFICATE-----", "privateKey": "-----BEGIN ENCRYPTED PRIVATE KEY----- MIIFKzBVBgkqhkiG9w0BBQ0wSDAnBgkqhkiG9w0BBQwwGgQUiAFcK5hT/X7Kjmgp ... QrSekqF+kWzmB6nAfSzgO9IaoAaytLvNgGTckWeUkWn/V0Ck+LdGUXzAC4RxZnoQ zp2mwJn2NYB7AZ7+imp0azDZb+8YG2aUCiyqb6PnnA== -----END ENCRYPTED PRIVATE KEY-----" }
Para obter mais informações sobre o mTLS para Amazon MSK e instruções para gerar um certificado de cliente, consulte Mutual TLS client authentication for Amazon MSK no Amazon Managed Streaming for Apache Kafka Developer Guide.
Autenticação do IAM
Você pode usar o AWS Identity and Access Management (IAM) para autenticar a identidade dos clientes que se conectam ao cluster do MSK. Com a autenticação do IAM, o Lambda depende das permissões do perfil de execução da função para se conectar ao cluster, recuperar registros e realizar outras ações necessárias. Para ver um exemplo de política com as permissões necessárias, consulte Create authorization policies for the IAM role no Amazon Managed Streaming for Apache Kafka Developer Guide.
Se a autenticação do IAM estiver ativa no cluster do MSK e você não fornecer um segredo, o Lambda usará automaticamente a autenticação do IAM por padrão.
Para obter mais informações sobre a autenticação do IAM no Amazon MSK, consulte IAM access control.
Como o Lambda escolhe um operador de bootstrap
O Lambda escolhe um operador de bootstrap com base nos métodos de autenticação disponíveis no cluster e dependendo de você fornecer um segredo para autenticação. Se você fornecer um segredo para mTLS ou SASL/SCRAM, o Lambda escolherá esse método de autenticação automaticamente. Se você não fornecer um segredo, o Lambda selecionará o método de autenticação mais forte que estiver ativo no seu cluster. Veja a seguir a ordem de prioridade na qual o Lambda seleciona um operador, da autenticação mais forte para a mais fraca:
mTLs (segredo fornecido para mTLs)
SASL/SCRAM (segredo fornecido para SASL/SCRAM)
SASL IAM (nenhum segredo fornecido, e a autenticação do IAM está ativa)
TLS não autenticado (nenhum segredo fornecido, e a autenticação do IAM não está ativa)
Texto simples (nenhum segredo fornecido, e a autenticação do IAM e o TLS não autenticado não estão ativos)
nota
Se o Lambda não conseguir se conectar ao tipo de operador mais seguro, o Lambda não tentará se conectar a um tipo de operador diferente (mais fraco). Se quiser que o Lambda escolha um tipo de operador mais fraco, desative todos os métodos de autenticação mais fortes no seu cluster.
