# Usar o Lambda com o Apache Kafka autogerenciado Este tópico descreve como usar o Lambda com um cluster Kafka autogerenciado. Na terminologia da AWS, um cluster autogerenciado inclui clusters do Kafka não hospedados pela AWS. Por exemplo, você pode hospedar seu cluster do Kafka com um provedor de nuvem, como [Confluent Cloud](https://www.confluent.io/confluent-cloud/) ou [Redpanda](https://www.redpanda.com/). Este capítulo explica como usar um cluster do Apache Kafka autogerenciado como origem do evento para a função do Lambda. O processo geral de integração do Apache Kafka autogerenciado com o Lambda envolve as seguintes etapas: 1. **[Configuração de cluster e rede](with-kafka-cluster-network.md)**: primeiro, configure seu cluster do Apache Kafka autogerenciado com a configuração de rede correta para permitir que o Lambda acesse seu cluster. 1. **[Configuração do mapeamento da origem do evento](with-kafka-configure.md)**: depois, crie o recurso de [mapeamento da origem do evento](invocation-eventsourcemapping.md) de que o Lambda precisa para se conectar ao cluster Apache Kafka à função com segurança. 1. **[Configuração da função e das permissões](with-kafka-permissions.md)**: por fim, certifique-se de que a função esteja configurada corretamente e tenha as permissões exigidas em seu [perfil de execução](lambda-intro-execution-role.md). O Apache Kafka como uma fonte de eventos opera de forma semelhante ao uso do Amazon Simple Queue Service (Amazon SQS) ou do Amazon Kinesis. O Lambda pesquisa internamente por novas mensagens da origem do evento e, em seguida, chama de forma síncrona a função do Lambda de destino. O Lambda lê as mensagens em lotes e fornece estas para a sua função como uma carga de eventos. O tamanho máximo do lote é configurável (o padrão é 100 mensagens). Para obter mais informações, consulte [Comportamento de lotes](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching). Para otimizar o throughput do mapeamento da origem de eventos do Apache Kafka autogerenciado, configure o modo provisionado. No modo provisionado, você pode definir o número mínimo e máximo de agentes de sondagem de eventos alocados para o mapeamento da origem de eventos. Isso pode melhorar a capacidade do mapeamento da origem de eventos para lidar com picos inesperados de mensagens. Para obter mais informações, consulte [ modo provisionado](kafka-scaling-modes.md#kafka-provisioned-mode). **Atenção** Os mapeamentos da origem do evento do Lambda processam cada evento ao menos uma vez, podendo haver o processamento duplicado de registros. Para evitar possíveis problemas relacionados a eventos duplicados, é altamente recomendável tornar o código da função idempotente. Para saber mais, consulte [Como tornar minha função do Lambda idempotente](https://repost.aws/knowledge-center/lambda-function-idempotent) no Centro de Conhecimentos da AWS. Para fontes de eventos baseadas em Kafka, o Lambda oferece suporte a parâmetros de controle de processamento, como janelas de lotes e tamanho do lote. Para obter mais informações, consulte [Comportamento de lotes](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching). Para obter um exemplo de como usar o Kafka autogerenciado como uma fonte de eventos, consulte [Usar o Apache Kafka auto-hospedado como uma fonte de eventos para o AWS Lambda](https://aws.amazon.com/blogs/compute/using-self-hosted-apache-kafka-as-an-event-source-for-aws-lambda/) no Blog de computação da AWS. **Topics** + [Evento de exemplo](#smaa-sample-event) + [Configurar o cluster do Apache Kafka autogerenciado e a rede do Lambda](with-kafka-cluster-network.md) + [Configurar as permissões do perfil de execução do Lambda](with-kafka-permissions.md) + [Configurar origens de eventos do Apache Kafka autogerenciado para o Lambda](with-kafka-configure.md) ## Evento de exemplo O Lambda envia o lote de mensagens no parâmetro de evento quando ele invoca sua função do Lambda. O payload do evento contém uma matriz de mensagens. Cada item da matriz contém detalhes do tópico do Kafka e do identificador de partição do Kafka, juntamente com um carimbo de data/hora e uma mensagem codificada em base64. ``` { "eventSource": "SelfManagedKafka", "bootstrapServers":"b-2.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092,b-1.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092", "records":{ "mytopic-0":[ { "topic":"mytopic", "partition":0, "offset":15, "timestamp":1545084650987, "timestampType":"CREATE_TIME", "key":"abcDEFghiJKLmnoPQRstuVWXyz1234==", "value":"SGVsbG8sIHRoaXMgaXMgYSB0ZXN0Lg==", "headers":[ { "headerKey":[ 104, 101, 97, 100, 101, 114, 86, 97, 108, 117, 101 ] } ] } ] } } ``` # Configurar o cluster do Apache Kafka autogerenciado e a rede do Lambda Para conectar a função do Lambda ao cluster do Apache Kafka autogerenciado, é preciso configurar corretamente o cluster e a rede em que ele reside. Esta página descreve como configurar o cluster e a rede. Se o cluster e a rede já estiverem configurados corretamente, consulte [Configurar origens de eventos do Apache Kafka autogerenciado para o Lambda](with-kafka-configure.md) para configurar o mapeamento da origem do evento. **Topics** + [Configuração do cluster do Apache Kafka autogerenciado](#kafka-cluster-setup) + [Configuração da segurança de rede](#services-kafka-vpc-config) ## Configuração do cluster do Apache Kafka autogerenciado Você pode hospedar seu cluster do Apache Kafka autogerenciado com provedores de nuvem, como [Confluent Cloud](https://www.confluent.io/confluent-cloud/) ou [Redpanda](https://www.redpanda.com/), ou executá-lo em sua própria infraestrutura. Certifique-se de que seu cluster esteja devidamente configurado e acessível a partir da rede à qual seu mapeamento da origem do evento Lambda se conectará. ## Configuração da segurança de rede Para conceder ao Lambda acesso total ao Apache Kafka autogerenciado 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 Apache Kafka autogerenciado com o Lambda, recomendamos a criação de [endpoints de VPC do AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) para conceder acesso da sua função aos recursos na sua Amazon VPC. **nota** Os endpoints de VPC do AWS PrivateLink são necessários para funções com mapeamentos da origem de eventos que usam o modo padrão (sob demanda) para pesquisadores de eventos. Se o mapeamento da origem do evento usa o [modo provisionado](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode), você não precisa configurar endpoints de VPC do AWS PrivateLink. Crie um endpoint para fornecer acesso aos seguintes recursos: + Lambda: crie um endpoint para a entidade principal de serviço do Lambda. + AWS STS: crie um endpoint para o AWS STS com a finalidade de possibilitar que uma entidade principal de serviço assuma um perfil em seu nome. + Secrets Manager: caso o seu cluster use o Secrets Manager para armazenar credenciais, crie um endpoint específico para o Secrets Manager. Como alternativa, configure um gateway NAT em cada sub-rede pública da Amazon VPC. Para obter mais informações, consulte [Habilitar o acesso à Internet para funções do Lambda conectadas à VPC](configuration-vpc-internet.md). Ao criar um mapeamento da origem do evento para o Apache Kafka autogerenciado, 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. **nota** As funções do Lambda sempre são executadas em VPCs de propriedade do serviço Lambda. A configuração de VPC da sua função não afetará o mapeamento da origem do evento. Somente a configuração de rede da origem dos eventos determina como o Lambda estabelece conexão com a origem dos eventos. Configure os grupos de segurança para a Amazon VPC que contém o cluster. Por padrão, o Apache Kafka autogerenciado usa a seguinte porta: `9092`. + Regras de entrada: permitem todo o tráfego na porta padrão do agente para o grupo de segurança associado à origem dos eventos. Como alternativa, é possível usar uma regra de grupo de segurança autorreferenciada para permitir o acesso de instâncias dentro do mesmo grupo de segurança. + Regras de saída: permitir todo o tráfego na porta `443` para destinos externos se sua função precisar se comunicar com serviços da AWS. Como alternativa, você também poderá usar uma regra de grupo de segurança autorreferenciada para limitar o acesso ao operador se não precisar se comunicar com outros serviços AWS. + Regras de entrada para o endpoint da Amazon VPC: caso você esteja usando um endpoint da Amazon VPC, o grupo de segurança associado ao endpoint da Amazon VPC deve permitir o tráfego de entrada na porta `443` usando o grupo de segurança do cluster. 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. **Example Política de endpoint da VPC: endpoint do Secrets Manager** ``` { "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. **Example Política de endpoint da VPC: endpoint do AWS STS** ``` { "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] } ``` **Example Política de endpoint da VPC: endpoint do Lambda** ``` { "Statement": [ { "Action": "lambda:InvokeFunction", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] } ``` # Configurar as permissões do perfil de execução do Lambda Além de [acessar seu cluster autogerenciado do Kafka](kafka-cluster-auth.md), sua função do Lambda necessita de permissões para executar várias ações da API. Adicione essas permissões à [função de execução](lambda-intro-execution-role.md) da função. Se os usuários precisarem acessar alguma ação da API, adicione as permissões necessárias à política de identidade para o usuário ou a função do AWS Identity and Access Management (IAM). **Topics** + [Permissões de função do Lambda necessárias](#smaa-api-actions-required) + [Permissões de função do Lambda opcionais](#smaa-api-actions-optional) + [Adicionar permissões à sua função de execução](#smaa-permissions-add-policy) + [Conceder acesso aos usuários com uma política do IAM](#smaa-permissions-add-users) ## Permissões de função do Lambda necessárias Para criar e armazenar logs em um grupo de logs do Amazon CloudWatch Logs, sua função Lambda deve ter as seguintes permissões na função de execução: + [logs:CreateLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html) + [logs:CreateLogStream](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogStream.html) + [logs:PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html) ## Permissões de função do Lambda opcionais Sua função Lambda também pode precisar dessas permissões para: + Descreva o segredo do Secrets Manager. + Acessar a chave gerenciada pelo cliente AWS Key Management Service (AWS KMS) + Acesse sua Amazon VPC. + Enviar registros de invocações com falha para um destino ### Secrets Manager e permissões do AWS KMS Conforme o tipo de controle de acesso que você está configurando para seus agentes do Kafka, sua função Lambda poderá precisar de permissão para acessar seu segredo do Secrets Manager ou 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: + [secretsmanager:GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) + [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) ### Permissões da VPC Se somente usuários dentro de uma VPC puderem acessar seu cluster do Apache Kafka autogerenciado, a função 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, a função de execução da função precisa ter as seguintes permissões: + [ec2:CreateNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkInterface.html) + [ec2:DescribeNetworkInterfaces](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeNetworkInterfaces.html) + [ec2:DescribeVpcs](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html) + [ec2:DeleteNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkInterface.html) + [ec2:DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html) + [ec2:DescribeSecurityGroups](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSecurityGroups.html) ## Adicionar permissões à sua função de execução Para acessar outros serviços da AWS que seu cluster autogerenciado do Apache Kafka usa, o Lambda utiliza as políticas de permissão que você define na [função de execução](lambda-intro-execution-role.md) da função do Lambda. Por padrão, o Lambda não pode executar as ações obrigatórias ou opcionais para um cluster do Apache Kafka autogerenciado. Você deve criar e definir essas ações em uma [política de confiança do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html) para seu perfil de execução. Este exemplo mostra como criar uma política que permita que o Lambda acesse seus recursos da Amazon VPC. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "ec2:CreateNetworkInterface", "ec2:DescribeNetworkInterfaces", "ec2:DescribeVpcs", "ec2:DeleteNetworkInterface", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups" ], "Resource":"*" } ] } ``` ------ ## 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 de origem de eventos](invocation-eventsourcemapping.md#event-source-mapping-api). Para conceder acesso a usuários de sua organização ou conta, crie ou atualize uma política baseada em identidades. Para obter mais informações, consulte [Controlar o acesso aos recursos da AWS usando políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html) no *Manual do usuário do IAM*. Para solução de problemas de erros comuns de autenticação e de autorização, consulte [Solução de problemas de erros do mapeamento da origem do evento do Kafka](with-kafka-troubleshoot.md). # Configurar origens de eventos do Apache Kafka autogerenciado para o Lambda Para usar um cluster do Apache Kafka autogerenciado como origem de eventos para a função do Lambda, você deve criar um [mapeamento da origem do evento](invocation-eventsourcemapping.md) que conecta os dois recursos. Esta página descreve como criar um mapeamento da origem do evento para o Apache Kafka autogerenciado. Esta página pressupõe que você já configurou adequadamente o cluster do Kafka e em que ele reside. Se você precisar configurar seu cluster ou sua rede, consulte [Configurar o cluster do Apache Kafka autogerenciado e a rede do Lambda](with-kafka-cluster-network.md). **Topics** + [Como usar um cluster do Apache Kafka autogerenciado como uma origem do evento](#kafka-esm-overview) + [Configurar métodos de autenticação de cluster no Lambda](kafka-cluster-auth.md) + [Criar um mapeamento da origem do evento do Lambda para uma origem de evento do Apache Kafka autogerenciado](kafka-esm-create.md) + [Todos os parâmetros de configuração da origem do evento do Apache Kafka autogerenciado no Lambda](kafka-esm-parameters.md) ## Como usar um cluster do Apache Kafka autogerenciado como uma origem do evento Quando você adiciona seu cluster do Apache Kafka ou do Amazon MSK como um gatilho para a função do Lambda, o cluster é usado como uma [origem de eventos](invocation-eventsourcemapping.md). O Lambda lê os dados de eventos dos tópicos do Kafka que você especifica como `Topics` em uma solicitação de [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) com base na [posição inicial](kafka-starting-positions.md) especificada. Após o processamento bem-sucedido, seu tópico do Kafka é confirmado no cluster do Kafka. O Lambda lê as mensagens sequencialmente para cada partição de tópico do Kafka. Uma única carga do Lambda pode conter mensagens de várias partições. Quando mais registros ficam disponíveis, o Lambda continua processando os registros em lotes, com base no valor de BatchSize especificado na solicitação de [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html), até a função estar atualizada com o tópico. Depois que o Lambda processa cada lote, ele confirma os deslocamentos das mensagens nesse lote. Se sua função retorna um erro para qualquer uma das mensagens em um lote, o Lambda tenta novamente todo o lote de mensagens até que o processamento seja bem-sucedido ou as mensagens expiram. É possível enviar registros que apresentaram falha em todas as tentativas a um destino em caso de falha para processamento posterior. **nota** Embora as funções do Lambda normalmente tenham um limite máximo de tempo de 15 minutos, os mapeamentos da origem dos eventos para o Amazon MSK, o Apache Kafka autogerenciado, o Amazon DocumentDB e o Amazon MQ para ActiveMQ e RabbitMQ são compatíveis somente com funções com limites máximos de tempo limite de 14 minutos. # Configurar métodos de autenticação de cluster no Lambda O Lambda suporta vários métodos para autenticar com seu cluster Apache Kafka autogerenciado. Configure o cluster Kafka para utilizar um dos métodos de autenticação compatíveis. Para obter mais informações sobre a segurança do Kafka, consulte a seção [Segurança](http://kafka.apache.org/documentation.html#security) da documentação do Kafka. ## Autenticação SASL/SCRAM O Lambda oferece suporte à autenticação Simple Authentication e Security Layer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM) com criptografia (`SASL_SSL`) Transport Layer Security (TLS). O Lambda envia as credenciais criptografadas para autenticar com o cluster. O Lambda não oferece suporte a SASL/SCRAM com texto simples (`SASL_PLAINTEXT`). Para obter mais informações sobre a autenticação do SASL/SCRAM, consulte [RFC 5802](https://tools.ietf.org/html/rfc5802). O Lambda também oferece suporte à autenticação SASL/PLAIN. Como esse mecanismo usa credenciais de texto não criptografado, a conexão com o servidor deve usar criptografia TLS para garantir que as credenciais sejam protegidas. Para a autenticação SASL, armazene as credenciais de login como um segredo no AWS Secrets Manager. Para obter mais informações sobre o uso do Secrets Manager, consulte [Create an AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) no *AWS Secrets Manager User Guide*. **Importante** Para usar o Secrets Manager para autenticação, os segredos devem estar armazenados na mesma região da AWS que sua função do Lambda. ## 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 Apache Kafka autogerenciado, o Lambda atua como cliente. Você configura um certificado de cliente (como um segredo no Secrets Manager) para autenticar o Lambda com os agentes do Kafka. O certificado do cliente deve ser assinado por uma autoridade de certificação no armazenamento de confiança do servidor. O cluster do Kafka envia um certificado de servidor ao Lambda para autenticar os agentes do Kafka com o Lambda. O certificado do servidor pode ser um certificado CA público ou um certificado de CA privado/autoassinado. O certificado CA público deve ser assinado por uma autoridade de certificação (CA) que esteja no repositório de confiança do Lambda. Para um certificado CA privado/autoassinado, configure o certificado CA raiz do servidor (como um segredo no Secrets Manager). O Lambda usa o certificado raiz para verificar os agentes do Kafka. Para obter mais informações sobre o mTLS, consulte [Introducing mutual TLS authentication for Amazon MSK as an event source](https://aws.amazon.com/blogs/compute/introducing-mutual-tls-authentication-for-amazon-msk-as-an-event-source) (Introdução à autenticação TLS mútua para o Amazon MSK como fonte de eventos). ## Configurar o segredo do certificado do cliente 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 de 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-----" } ``` ## Configurar o segredo do certificado CA raiz do servidor Crie esse segredo se seus agentes do Kafka usarem criptografia TLS com certificados assinados por uma CA privada. É possível usar criptografia TLS para autenticação de VPC, SASL/SCRAM, SASL/PLAIN ou mTLS. O segredo do certificado CA raiz do servidor requer um campo que contenha o certificado CA raiz do agente do Kafka no formato PEM. O exemplo a seguir exibe a estrutura do segredo. ``` {"certificate":"-----BEGIN CERTIFICATE----- MIID7zCCAtegAwIBAgIBADANBgkqhkiG9w0BAQsFADCBmDELMAkGA1UEBhMCVVMx EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAjBgNVBAoT HFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xOzA5BgNVBAMTMlN0YXJmaWVs ZCBTZXJ2aWNlcyBSb290IENlcnRpZmljYXRlIEF1dG... -----END CERTIFICATE-----" } ``` # Criar um mapeamento da origem do evento do Lambda para uma origem de evento do Apache Kafka autogerenciado Para criar um mapeamento da origem do evento, você pode usar o console do Lambda, a [AWS Command Line Interface (CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) ou um [SDK da AWS](https://aws.amazon.com/getting-started/tools-sdks/). As etapas do console a seguir adicionam um cluster do Apache Kafka autogerenciado como acionador da função do Lambda. Nos bastidores, isso cria um recurso de mapeamento da origem do evento. ## Pré-requisitos + Um cluster Apache Kafka autogerenciado. O Lambda é compatível com o Apache Kafka versão 0.10.1.0 e posteriores. + Uma [função de execução](lambda-intro-execution-role.md) com permissão para acessar os recursos da AWS que o cluster do Kafka autogerenciado usa. ## Adicionando um cluster Kafka autogerenciado (console) Siga estas etapas para adicionar seu cluster autogerenciado do Apache Kafka e um tópico do Kafka como um acionador para sua função do Lambda. **Para adicionar um acionador do Apache Kafka à sua função do Lambda (console)** 1. Abra a página [Functions](https://console.aws.amazon.com/lambda/home#/functions) (Funções) no console do Lambda. 1. Escolha o nome da função do Lambda. 1. Em **Visão geral da função**, escolha **Adicionar gatilho**. 1. Em **Trigger configuration** (Configuração do acionador), faça o seguinte: 1. Selecione o tipo de acionadro **Apache Kafka**. 1. Para **Servidores de bootstrap**, insira o endereço de host e par de portas de um corretor Kafka em seu cluster e escolha **Adicionar**. Repita para cada agente da Kafka no cluster. 1. Em **Nome do tópico**, insira o nome do tópico do Kafka usado para armazenar registros no cluster. 1. Se você configurar o modo provisionado, insira um valor para **Mínimo de agentes de sondagem de eventos**, um valor para **Máximo de agentes de sondagem de eventos** e um valor opcional para PollerGroupName para especificar o agrupamento de vários ESMs na mesma VPC de origem dos eventos. 1. (Opcional) Em **Tamanho do lote**, insira o número máximo de registros a serem recebidos em um único lote. 1. Em **Batch window** (Janela de lote), insira o tempo máximo em segundos usado pelo Lambda para coletar os registros antes de invocar a função. 1. (Opcional) em **Consumer group ID** (ID do grupo de consumidores), insira o ID de um grupo de consumidores do Kafka no qual ingressar. 1. (Opcional) Em **Posição inicial**, escolha **Mais recente** para começar a realizar a leitura do fluxo a partir do registro mais recente, **Horizonte de corte** para começar no registro mais antigo disponível ou **No timestamp** para especificar um timestamp para começar a realizar a leitura. 1. (Opcional) Em **VPC**, escolha a Amazon VPC para seu cluster do Kafka. Em seguida, escolha **VPC subnets** (Sub-redes da VPC) e **VPC security groups** (Grupos de segurança da VPC). Essa configuração será necessária se apenas os usuários da VPC acessarem seus agentes. 1. (Opcional) Em **Authentication** (Autenticação), escolha **Add** (Adicionar) e faça o seguinte: 1. Escolha o protocolo de acesso ou a autenticação dos agentes do Kafka no cluster. + Se o agente do Kafka usar autenticação SASL/PLAIN, escolha **BASIC\$1AUTH**. + Se seu agente usar autenticação SASL/SCRAM, escolha um dos protocolos **SASL\$1SCRAM**. + Se estiver configurando a autenticação mTLS, escolha o protocolo **CLIENT\$1CERTIFICATE\$1TLS\$1AUTH**. 1. Para a autenticação SASL/SCRAM ou mTLS, escolha a chave secreta do Secrets Manager que contém as credenciais de seu cluster do Kafka. 1. (Opcional) Em **Encryption** (Criptografia), escolha o segredo do Secrets Manager que contém o certificado CA raiz que seus agentes do Kafka usam para criptografia TLS, se seus agentes do Kafka usarem certificados assinados por uma CA privada. Essa configuração se aplica à criptografia TLS para SASL/SCRAM ou SASL/PLAIN e à autenticação MTLs. 1. Para criar o gatilho em um estado desativado para teste (recomendado), desmarque **Ativar gatilho**. Ou, para habilitar o gatilho imediatamente, selecione **Ativar gatilho**. 1. Para criar o acionador, selecione **Add** (Adicionar). ## Adicionando um cluster Kafka autogerenciado (AWS CLI) Use os comandos de exemplo da AWS CLI a seguir para criar e visualizar um acionador autogerenciado do Apache Kafka para sua função do Lambda. ### Usar SASL/SCRAM Se usuários do Kafka acessarem seus agentes do Kafka pela Internet, especifique o segredo do Secrets Manager criado para autenticação SASL/SCRAM. O exemplo a seguir usa o comando [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) da AWS CLI para mapear uma função do Lambda chamada `my-kafka-function` em um tópico do Kafka chamado `AWSKafkaTopic`. ``` aws lambda create-event-source-mapping \ --topics AWSKafkaTopic \ --source-access-configuration Type=SASL_SCRAM_512_AUTH,URI=arn:aws:secretsmanager:us-east-1:111122223333:secret:MyBrokerSecretName \ --function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \ --self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}' ``` ### Usar uma VPC Se apenas os usuários do Kafka em sua VPC acessarem seus agentes do Kafka, você deverá especificar sua VPC, suas sub-redes e seu grupo de segurança da VPC. O exemplo a seguir usa o comando [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) da AWS CLI para mapear uma função do Lambda chamada `my-kafka-function` em um tópico do Kafka chamado `AWSKafkaTopic`. ``` aws lambda create-event-source-mapping \ --topics AWSKafkaTopic \ --source-access-configuration '[{"Type": "VPC_SUBNET", "URI": "subnet:subnet-0011001100"}, {"Type": "VPC_SUBNET", "URI": "subnet:subnet-0022002200"}, {"Type": "VPC_SECURITY_GROUP", "URI": "security_group:sg-0123456789"}]' \ --function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \ --self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}' ``` ### Visualizar o status usando a AWS CLI O exemplo a seguir usa o comando [get-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-event-source-mapping.html) da AWS CLI para descrever o status do mapeamento da origem do evento que você criou. ``` aws lambda get-event-source-mapping --uuid dh38738e-992b-343a-1077-3478934hjkfd7 ``` # Todos os parâmetros de configuração da origem do evento do Apache Kafka autogerenciado no Lambda Todos os tipos de origem de evento Lambda compartilham o mesmo[CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)e[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)Operações de API do. Porém, apenas alguns dos parâmetros se aplicam ao Apache Kafka autogerenciado, como mostra a tabela a seguir. | Parâmetro | Obrigatório | Padrão | Observações | | --- | --- | --- | --- | | BatchSize | N | 100 | Máximo: 10.000. | | DestinationConfig | N | N/D | [Capturar lotes descartados para uma origem do evento do Amazon MSK e do Apache Kafka autogerenciado](kafka-on-failure.md) | | Habilitado | N | Verdadeiro | | | FilterCriteria | N | N/D | [Controlar quais eventos o Lambda envia para a função](invocation-eventfiltering.md) | | FunctionName | S | N/D | | | KMSKeyArn | N | N/D | [Criptografia de critérios de filtro](invocation-eventfiltering.md#filter-criteria-encryption) | | MaximumBatchingWindowInSeconds | N | 500 ms | [Comportamento de lotes](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching) | | ProvisionedPollersConfig | N | `MinimumPollers`: o valor padrão será 1 se não for especificado. `MaximumPollers`: o valor padrão será 200 se não for especificado. `PollerGroupName`: N/D | [Modo provisionado](kafka-scaling-modes.md#kafka-provisioned-mode) | | SelfManageDeventSource | S | N/D | Lista de corretores Kafka. Pode definir apenas em Criar | | SelfManagedKafkaEventSourceConfig | N | Contém o campo ConsumerGroupId que assume por padrão um valor exclusivo. | Pode definir apenas em Criar | | SourceAccessConfigurations | N | Nenhuma credencial | Informações da VPC ou credenciais de autenticação para o cluster Para SASL\$1PLAIN, defina como BASIC\$1AUTH | | StartingPosition | S | N/D | AT\$1TIMESTAMP, TRIM\$1HORIZON, ou LATEST Pode definir apenas em Criar | | StartingPositionTimestamp | N | N/D | Obrigatório se StartingPosition estiver definido como AT\$1TIMESTAMP | | Tags | N | N/D | [Uso de tags em mapeamentos da origem do evento](tags-esm.md) | | Tópicos | S | N/D | Nome do tópico Pode definir apenas em Criar | **nota** Quando você especifica um `PollerGroupName`, vários ESMs dentro da mesma Amazon VPC podem compartilhar a capacidade da unidade de sondagem de evento (EPU). É possível usar essa opção para otimizar os custos do modo provisionado para seus ESMs. Requisitos para o agrupamento de ESM: Os ESMs devem estar na mesma Amazon VPC Máximo de 100 ESMs por grupo de agentes de sondagem O máximo agregado de agentes de sondagem em todos os ESMs em um grupo não pode exceder a 2.000 É possível atualizar o `PollerGroupName` para mover um ESM para um grupo diferente ou remover um ESM de um grupo configurando `PollerGroupName` como uma string vazia (“”).