# Configuração de métodos de autenticação de cluster do Amazon MSK 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.
**Topics**
+ [Acesso não autenticado](#msk-unauthenticated)
+ [Autenticação SASL/SCRAM](#msk-sasl-scram)
+ [Autenticação TLS mútua](#msk-mtls)
+ [Autenticação do IAM](#msk-iam-auth)
+ [Como o Lambda escolhe um operador de bootstrap](#msk-bootstrap-brokers)
## 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)](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password-tutorial.html), 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](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html) no *Amazon Managed Streaming for Apache Kafka Developer Guide*.
**nota**
O Amazon MSK não oferece suporte 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 servidor deve ser assinado por uma autoridade de certificação (CA) no armazenamento de confiança da .
+ 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](https://docs.aws.amazon.com/msk/latest/developerguide/msk-encryption.html) assinados por [CAs do Amazon Trust Services](https://www.amazontrust.com/repository/), em que o Lambda confia por padrão.
### Configurar o segredo de mTLS
O segredo CLIENT\$1CERTIFICATE\$1TLS\$1AUTH 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](https://datatracker.ietf.org/doc/html/rfc2898/#section-6.1) (mas não PBES2).
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-----
-----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 \$18](https://datatracker.ietf.org/doc/html/rfc5208), com a seguinte estrutura:
```
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
```
Para uma chave privada criptografada, use a seguinte estrutura:
```
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----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](https://docs.aws.amazon.com/msk/latest/developerguide/msk-authentication.html) no *Amazon Managed Streaming for Apache Kafka Developer Guide*.
## Autenticação do IAM
É possível 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](lambda-intro-execution-role.md) 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](https://docs.aws.amazon.com/msk/latest/developerguide/create-iam-access-control-policies.html) 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](https://docs.aws.amazon.com/msk/latest/developerguide/iam-access-control.html).
## Como o Lambda escolhe um operador de bootstrap
O Lambda escolhe um [operador de bootstrap](https://docs.aws.amazon.com/msk/latest/developerguide/msk-get-bootstrap-brokers.html) 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.