Configurar as origens de eventos do Amazon MSK para o Lambda

Antes de criar um mapeamento da origem do evento para o cluster do Amazon MSK, é preciso garantir que o cluster e a VPC em que ele reside estejam configurados corretamente. Você também precisa garantir que o perfil de execução da função do Lambda tenha as permissões necessárias do IAM.

Siga as instruções das próximas seções para configurar o cluster do Amazon MSK, a VPC e a função do Lambda. Para saber como criar o mapeamento da origem do evento, consulte Adicionar o Amazon MSK como uma origem de evento.

Autenticação de cluster do MSK

O Lambda precisa de permissão para acessar o cluster do Amazon MSK, recuperar registros e executar outras tarefas. O Amazon MSK oferece suporte a várias opções para controlar o acesso do cliente ao cluster do MSK.

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 Amazon MSK é compatível com autenticação Simple Authentication e Security Layer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM) com criptografia Transport Layer Security (TLS). Para que o Lambda se conecte ao cluster, é necessário armazenar as credenciais de autenticação (nome de usuário e senha) em um segredo do AWS Secrets Manager.

Para obter mais informações sobre o uso do Secrets Manager, consulte Autenticação de nome de usuário e senha com o AWS Secrets Manager, no Guia do Desenvolvedor do Amazon Managed Streaming para Apache Kafka.

O Amazon MSK não oferece suporte a autenticação SASL/PLAIN.

Autenticação baseada em função do IAM

Use o IAM para autenticar a identidade dos clientes que se conectam ao cluster do MSK. Se a autenticação do IAM estiver ativa no cluster do MSK, e você não fornecer um segredo para autenticação, o Lambda usará automaticamente a autenticação do IAM por padrão. Para criar e implantar políticas baseadas em perfil ou usuário, use o console ou a API do IAM. Para obter mais informações, consulte IAM access control (Controle de acesso do IAM) no Guia do desenvolvedor do Amazon Managed Streaming for Apache Kafka.

Para permitir que o Lambda se conecte ao cluster do MSK, leia registros e execute outras ações necessárias, adicione as permissões a seguir à função de execução da função.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:Connect",
                "kafka-cluster:DescribeGroup",
                "kafka-cluster:AlterGroup",
                "kafka-cluster:DescribeTopic",
                "kafka-cluster:ReadData",
                "kafka-cluster:DescribeClusterDynamicConfiguration"
            ],
            "Resource": [
                "arn:aws:kafka:region:account-id:cluster/cluster-name/cluster-uuid",
                "arn:aws:kafka:region:account-id:topic/cluster-name/cluster-uuid/topic-name",
                "arn:aws:kafka:region:account-id:group/cluster-name/cluster-uuid/consumer-group-id"
            ]
        }
    ]
}       

É possível definir o escopo dessas permissões para abranger clusters, tópicos e grupos específicos. Para obter mais informações, consulte Amazon MSK Kafka actions (Ações do Amazon MSK Kafka) no Guia do desenvolvedor Amazon Managed Streaming for Apache Kafka.

Autenticação TLS mútua

O TLS mútuo (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, e o servidor envia um certificado ao cliente para que o cliente verifique o servidor.

No Amazon MSK, o Lambda atua como cliente. Configure um certificado de cliente (como um segredo no Secrets Manager) para autenticar o Lambda com os agentes no cluster do MSK. O certificado do cliente deve ser assinado por uma autoridade de certificação no armazenamento de confiança do servidor. O cluster do MSK envia um certificado de servidor ao Lambda para autenticar os agentes com o Lambda. O certificado do servidor deve ser assinado por uma autoridade de certificação (CA) no armazenamento de confiança da AWS.

Para obter instruções sobre como gerar um certificado de cliente, consulte Introducing mutual TLS authentication for Amazon MSK as an event source (Introdução à autenticação TLS mútua do Amazon MSK como fonte de eventos).

O Amazon MSK não oferece suporte a certificados de servidor autoassinados, pois todos os agentes no Amazon MSK usam certificados públicos assinados por CAs do Amazon Trust Services, nos quais o Lambda confia por padrão.

Para obter mais informações sobre o mTLS para o Amazon MSK, consulte Mutual TLS Authentication (Autenticação TLS mútua) no Guia do desenvolvedor Amazon Managed Streaming for Apache Kafka.

Configurar o segredo de mTLS

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.

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, com a seguinte estrutura:

-----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-----"
} 

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:

Gerenciar acesso e permissões de API

Além de acessar o cluster do Amazon MSK, a função Lambda precisa de permissões para executar várias ações de API do Amazon MSK. Adicione essas permissões à função de execução da função. Se os usuários precisarem acessar qualquer ação da API do Amazon MSK, adicione as permissões necessárias à política de identidade para o usuário ou o perfil.

É possível adicionar manualmente cada uma das permissões a seguir ao perfil de execução. Ou então, você pode anexar a política gerenciada pela AWS AWSLambdaMSKExecutionRole ao perfil de execução. A política AWSLambdaMSKExecutionRole contém todas as ações de API e permissões da VPC necessárias listadas abaixo.

Permissões necessárias da função de execução da função do Lambda

Para criar e armazenar logs em um grupo de logs do Amazon CloudWatch Logs, sua função do Lambda deve ter as seguintes permissões na função de execução:

Para que o Lambda acesse o cluster do Amazon por você, sua função do Lambda deve ter as seguintes permissões no perfil de execução:

Você só precisa adicionar kafka:DescribeCluster ou kafka:DescribeClusterV2. Para clusters do MSK provisionados, ambas as permissões funcionam. Para clusters do MSK com tecnologia sem servidor, é necessário usar kafka:DescribeClusterV2.

Permissões da VPC

Se somente usuários dentro de uma VPC puderem acessar seu cluster do Amazon MSK, a função do Lambda deverá ter permissão para acessar seus recursos da Amazon VPC. Esses recursos incluem sua VPC, sub-redes, security groups e interfaces de rede. Para acessar esses recursos, o perfil de execução da função precisa ter as permissões a seguir. Essas permissões estão incluídas na política gerenciada pela AWS AWSLambdaMSKExecutionRole.

Permissões de função do Lambda opcionais

Sua função Lambda também pode precisar dessas permissões para:

Secrets Manager e permissões do AWS KMS

Conforme o tipo de controle de acesso que você está configurando para os agentes do Amazon MSK, a função do Lambda pode precisar de permissão para acessar seu segredo do SCRAM (se usar autenticação SASL/SCRAM) ou o segredo do Secrets Manager para descriptografar sua chave do AWS KMS gerenciada pelo cliente. Para acessar esses recursos, a função de execução da função precisa ter as seguintes permissões:

Adicionar permissões à sua função de execução

Siga estas etapas para adicionar a política gerenciada pela AWS AWSLambdaMSKExecutionRole ao perfil de execução usando o console do IAM.

Conceder acesso aos usuários com uma política do IAM

Por padrão, usuários e perfis não têm permissão para executar operações de API do Amazon MSK. Para conceder acesso a usuários em sua organização ou conta, é possível adicionar ou atualizar uma política baseada em identidades. Para obter mais informações, consulte Exemplos de políticas baseadas em identidade do Amazon MSK no Guia do desenvolvedor do Amazon Managed Streaming for Apache Kafka.

Erros de autenticação e autorização

Se alguma das permissões necessárias para consumir dados do cluster do Amazon MSK estiver ausente, o Lambda exibirá uma mensagem de erro no mapeamento da fonte de eventos em LastProcessingResult.

O cluster falhou ao autorizar o Lambda

Para SASL/SCRAM ou mTLS, esse erro indica que o usuário fornecido não tem todas estas permissões da lista de controle de acesso (ACL) do Kafka necessárias:

Para controle de acesso do IAM, a função de execução da função não tem uma ou mais permissões necessárias para acessar o grupo ou tópico. Confira a lista de permissões necessárias em Autenticação baseada em função do IAM.

Ao criar ACLs do Kafka ou uma política do IAM com as permissões necessárias do cluster do Kafka, é necessário especificar o tópico e o grupo como recursos. O nome do tópico deve corresponder ao tópico no mapeamento da fonte de eventos. O nome do grupo deve corresponder ao UUID do mapeamento da fonte de eventos.

Depois de adicionar as permissões necessárias à função de execução, poderá levar vários minutos para que as alterações entrem em vigor.

SASL authentication failed (Falha na autenticação SASL)

Para SASL/SCRAM, esse erro indica que o nome de usuário e a senha fornecidos são inválidos.

Para controle de acesso do IAM, a função de execução não tem a permissão de kafka-cluster:Connect para o cluster do MSK. Adicione essa permissão à função e especifique o nome do recurso da Amazon (ARN) do cluster como recurso.

É possível que esse erro ocorra de modo intermitente. O cluster rejeitará conexões depois que o número de conexões de TCP exceder a cota de serviço do Amazon MSK. O Lambda recua e tenta novamente até que uma conexão seja bem-sucedida. Depois que o Lambda se conecta ao cluster e sonda por registros, o último resultado de processamento é alterado para OK.

Server failed to authenticate Lambda (Falha ao autenticar o Lambda no servidor)

Esse erro indica que não foi possível autenticar os agentes do Kafka do Amazon MSK com o Lambda. Esse erro pode ocorrer por estes motivos:

Provided certificate or private key is invalid (O certificado ou a chave privada fornecida é inválida)

Esse erro indica que o consumidor do Amazon MSK não conseguiu usar o certificado ou a chave privada fornecida. Verifique se o certificado e a chave usam o formato PEM e que a criptografia de chave privada usa um algoritmo PBES1.

Configuração da segurança de rede

Para conceder ao Lambda acesso total ao Amazon MSK por meio do mapeamento da origem do evento, seu cluster deve usar um endpoint público (endereço IP público) ou você deve fornecer acesso à Amazon VPC na qual o cluster foi criado.

Ao usar o Amazon MSK com o Lambda, recomendamos a criação de endpoints de VPC do AWS PrivateLink para conceder acesso da sua função aos recursos na sua Amazon VPC.

Crie um endpoint para fornecer acesso aos seguintes recursos:

Como alternativa, configure um gateway NAT em cada sub-rede pública da Amazon VPC. Para ter mais informações, consulte Habilitar o acesso à Internet para funções do Lambda conectadas à VPC.

Ao criar um mapeamento da origem do evento para o Amazon MSK, o Lambda verifica se as interfaces de rede elástica (ENIs) já estão presentes nas sub-redes e nos grupos de segurança configurados para a Amazon VPC. Se o Lambda encontrar ENIs existentes, ele tentará reutilizá-las. Caso contrário, o Lambda criará novas ENIs para se conectar à origem do evento e invocar sua função.

Configure os grupos de segurança para a Amazon VPC que contém o cluster. Por padrão, o Amazon MSK usa as seguintes portas: 9092 para texto simples, 9094 para o protocolo TLS, 9096 para a estrutura SASL e 9098 para o IAM.

Caso o cluster use autenticação, é possível restringir a política de endpoint para o endpoint do Secrets Manager. Para chamar a API do Secrets Manager, o Lambda usa seu perfil de função, e não a entidade principal de serviço do Lambda.

{
      "Statement": [
          {
              "Action": "secretsmanager:GetSecretValue",
              "Effect": "Allow",
              "Principal": {
                  "AWS": [
                      "arn:aws::iam::123456789012:role/my-role"
                  ]
              },
              "Resource": "arn:aws::secretsmanager:us-west-2:123456789012:secret:my-secret"
          }
      ]
  }

Quando você usa os endpoints da Amazon VPC, a AWS roteia suas chamadas de API para invocar sua função usando a interface de rede elástica (ENI) do endpoint. A entidade principal do serviço Lambda precisa chamar lambda:InvokeFunction para quaisquer perfis e funções que usem essas ENIs.

Por padrão, os endpoints da Amazon VPC têm políticas do IAM abertas que permitem amplo acesso aos recursos. A prática recomendada é restringir essas políticas para executar as ações necessárias usando esse endpoint. Para garantir que seu mapeamento da origem do evento seja capaz de invocar sua função do Lambda, a política de endpoint da VPC deve permitir que a entidade principal do serviço Lambda chame sts:AssumeRole e lambda:InvokeFunction. A restrição de suas políticas de endpoint da VPC para permitir apenas chamadas de API originadas em sua organização impedirá o funcionamento adequado do mapeamento da origem do evento; portanto, "Resource": "*" é necessário nessas políticas.

O seguinte exemplo de políticas de endpoint da VPC mostra como conceder o acesso necessário à entidade principal do serviço Lambda para os endpoints do AWS STS e Lambda.

{
      "Statement": [
          {
              "Action": "sts:AssumeRole",
              "Effect": "Allow",
              "Principal": {
                  "Service": [
                      "lambda.amazonaws.com"
                  ]
              },
              "Resource": "*"
          }
      ]
    }

{
      "Statement": [
          {
              "Action": "lambda:InvokeFunction",
              "Effect": "Allow",
              "Principal": {
                  "Service": [
                      "lambda.amazonaws.com"
                  ]
              },
              "Resource": "*"
          }
      ]
  }