Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Utilizzo di Lambda con Apache Kafka gestito dal cliente Questo argomento descrive come utilizzare Lambda con un cluster Kafka autogestito. In AWS terminologia, un cluster autogestito include cluster Kafka non AWS ospitati. Ad esempio, è possibile ospitare il proprio cluster Kafka con un provider cloud come [Confluent Cloud](https://www.confluent.io/confluent-cloud/) o [Redpanda](https://www.redpanda.com/). Questo capitolo spiega come utilizzare un cluster Apache Kafka autogestito come origine di eventi per la funzione Lambda. Il processo generale per l'integrazione di Apache Kafka autogestito con Lambda prevede i seguenti passaggi: 1. **[Configurazione del cluster e della rete](with-kafka-cluster-network.md)**: per prima cosa, configura il cluster Apache Kafka autogestito con la configurazione di rete corretta per consentire a Lambda di accedere al cluster. 1. **[Configurazione della mappatura delle sorgenti degli eventi](with-kafka-configure.md)**: quindi, crea la risorsa di [mappatura delle sorgenti degli eventi](invocation-eventsourcemapping.md) di cui Lambda ha bisogno per connettere in modo sicuro il cluster Apache Kafka alla tua funzione. 1. **[Configurazione delle funzioni e delle autorizzazioni](with-kafka-permissions.md)**[: infine, assicurati che la funzione sia configurata correttamente e disponga delle autorizzazioni necessarie nel suo ruolo di esecuzione.](lambda-intro-execution-role.md) Apache Kafka come origine eventi funziona in modo simile all'utilizzo di Amazon Simple Queue Service (Amazon SQS) o Amazon Kinesis. Lambda interroga internamente i nuovi messaggi dell'origine eventi, quindi richiama in modo sincrono la funzione Lambda di destinazione. Lambda legge i messaggi in batch e li fornisce alla funzione come payload di evento. La dimensione massima del batch è configurabile (l'impostazione predefinita è 100 messaggi). Per ulteriori informazioni, consulta [Comportamento di batching](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching). Per ottimizzare il throughput dello strumento di mappatura dell'origine degli eventi di Apache Kafla autogestito, configura la modalità provisioning. In modalità provisioning, puoi definire il numero minimo e massimo di poller di eventi assegnati allo strumento di mappatura dell'origine degli eventi. Ciò può migliorare la capacità dello strumento di mappatura dell'origine degli eventi per gestire picchi di messaggi imprevisti. Per ulteriori informazioni, consulta [Modalità provisioning](kafka-scaling-modes.md#kafka-provisioned-mode). **avvertimento** Gli strumenti di mappatura dell'origine degli eventi elaborano ogni evento almeno una volta e può verificarsi un'elaborazione duplicata dei record. Per evitare potenziali problemi legati agli eventi duplicati, ti consigliamo vivamente di rendere idempotente il codice della funzione. Per ulteriori informazioni, consulta [Come posso rendere idempotente la mia funzione Lambda](https://repost.aws/knowledge-center/lambda-function-idempotent) nel Knowledge Center. AWS Per le origini eventi basate su KAFKA, Lambda supporta i parametri di controllo dell'elaborazione, come le finestre di batch e le dimensioni del batch. Per ulteriori informazioni, consulta [Comportamento di batching](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching). Per un esempio di come utilizzare Kafka autogestito come fonte di eventi, vedi [Utilizzo di Apache Kafka ospitato autonomamente come fonte di eventi per sul blog di Compute](https://aws.amazon.com/blogs/compute/using-self-hosted-apache-kafka-as-an-event-source-for-aws-lambda/). AWS Lambda AWS **Topics** + [ ## Esempio di evento ](#smaa-sample-event) + [ # Configurazione del cluster e della rete Apache Kafka autogestiti per Lambda ](with-kafka-cluster-network.md) + [ # Configurazione delle autorizzazioni del ruolo di esecuzione Lambda ](with-kafka-permissions.md) + [ # Configurazione di origini eventi Apache Kafka autogestito per Lambda ](with-kafka-configure.md) ## Esempio di evento Lambda invia il batch di messaggi nel parametro evento quando richiama la funzione Lambda. Il payload evento contiene un array di messaggi. Ogni elemento dell'array contiene i dettagli dell'argomento Kafka e dell'identificatore dello shard Kafka, insieme a una data/ora e a un messaggio con codifica 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 ] } ] } ] } } ``` # Configurazione del cluster e della rete Apache Kafka autogestiti per Lambda Per connettere la funzione Lambda al cluster Apache Kafka autogestito, devi configurare correttamente il cluster e la rete in cui si trova. Questa pagina spiega come configurare il cluster e la rete. Se il cluster e la rete sono già configurati correttamente, consulta [Configurazione di origini eventi Apache Kafka autogestito per Lambda](with-kafka-configure.md) Configurare la mappatura delle sorgenti degli eventi. **Topics** + [ ## Un cluster Apache Kafka autogestito. ](#kafka-cluster-setup) + [ ## Configurare la sicurezza della rete ](#services-kafka-vpc-config) ## Un cluster Apache Kafka autogestito. Puoi ospitare il tuo cluster Apache Kafka autogestito con provider di servizi cloud come [Confluent Cloud](https://www.confluent.io/confluent-cloud/) o [Redpanda](https://www.redpanda.com/) oppure eseguirlo sulla tua infrastruttura. Assicurati che il cluster sia configurato correttamente e accessibile dalla rete a cui si connetterà la mappatura delle sorgenti degli eventi Lambda. ## Configurare la sicurezza della rete Per concedere a Lambda l'accesso completo ad Apache Kafka autogestito tramite lo strumento di mappatura dell'origine degli eventi, il cluster deve utilizzare un endpoint pubblico (indirizzo IP pubblico) oppure devi fornire l'accesso all'Amazon VPC in cui hai creato il cluster. Quando usi Apache Kafka autogestito con Lambda, crea [endpoint VPC AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) che forniscono alla funzione l'accesso alle risorse del tuo Amazon VPC. **Nota** Gli endpoint VPC AWS PrivateLink sono necessari per le funzioni con lo strumento di mappatura dell'origine degli eventi delle origini degli eventi che utilizzano la modalità predefinita (on demand) per i poller degli eventi. Se lo strumento di mappatura dell'origine degli eventi utilizza la [modalità provisioning](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode), non è necessario configurare gli endpoint VPC AWS PrivateLink. Crea un endpoint per fornire l'accesso alle seguenti risorse: + Lambda: crea un endpoint per il principale del servizio Lambda. + AWS STS: crea un endpoint per AWS STS in modo che un principale del servizio possa assumere un ruolo per conto tuo. + Secrets Manager: se il tuo cluster utilizza Secrets Manager per archiviare le credenziali, crea un endpoint per Secrets Manager. In alternativa, configura un gateway NAT su ogni sottorete pubblica in Amazon VPC. Per ulteriori informazioni, consulta [Abilitare l'accesso a Internet per funzioni Lambda connesse a un VPC](configuration-vpc-internet.md). Quando crei uno strumento di mappatura dell'origine degli eventi per Apache Kafka autogestito, Lambda verifica se le interfacce di rete elastiche (ENI) sono già presenti per le sottoreti e i gruppi di sicurezza configurati per il tuo Amazon VPC. Se Lambda trova ENI esistenti, prova a riutilizzarle. Altrimenti, Lambda crea nuove ENI per connettersi all'origine dell'evento e richiamare la tua funzione. **Nota** Le funzioni Lambda vengono sempre eseguite all'interno di VPC di proprietà del servizio Lambda. La configurazione VPC della funzione non influisce sullo strumento di mappatura dell'origine degli eventi. Solo la configurazione di rete dell'origine dell'evento determina il modo in cui Lambda si connette all'origine dell'evento. Configura i gruppi di sicurezza per l'Amazon VPC contenente il tuo cluster. Per impostazione predefinita, Apache Kafka autogestito utilizza le seguenti porte: `9092`. + Regole in ingresso: consenti tutto il traffico sulla porta del broker predefinita per il gruppo di sicurezza associato all'origine eventi. In alternativa, puoi utilizzare una regola del gruppo di sicurezza autoreferenziante per consentire l'accesso da istanze all'interno dello stesso gruppo di sicurezza. + Regole in uscita: consenti tutto il traffico sulla porta `443` per destinazioni esterne se la funzione deve comunicare con AWS i servizi. In alternativa, puoi anche utilizzare una regola del gruppo di sicurezza autoreferenziale per limitare l'accesso al broker se non hai bisogno di comunicare con altri servizi. AWS + Regole di ingresso degli endpoint Amazon VPC: se utilizzi un endpoint Amazon VPC, il gruppo di sicurezza associato all'endpoint Amazon VPC deve consentire il traffico in entrata sulla porta `443` dal gruppo di sicurezza del cluster. Se il cluster utilizza l'autenticazione, puoi anche limitare la policy degli endpoint per l'endpoint Secrets Manager. Per chiamare l'API Secrets Manager, Lambda utilizza il ruolo della funzione, non il principale del servizio Lambda. **Example Policy dell'endpoint VPC: endpoint 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 utilizzi gli endpoint Amazon VPC, AWS indirizza le chiamate API per invocare la funzione utilizzando l'interfaccia di rete elastica (ENI) dell'endpoint. Il principale del servizio Lambda deve chiamare `lambda:InvokeFunction` su tutti i ruoli e le funzioni che utilizzano tali ENI. Per impostazione predefinita, gli endpoint Amazon VPC dispongono di policy IAM aperte che consentono un ampio accesso alle risorse. La best practice consiste nel limitare queste policy per eseguire le azioni necessarie utilizzando quell'endpoint. Per garantire che lo strumento di mappatura dell'origine degli eventi sia in grado di invocare la funzione Lambda, la policy degli endpoint VPC deve consentire al principale del servizio Lambda di chiamare `sts:AssumeRole` e `lambda:InvokeFunction`. Limitare le policy degli endpoint VPC per consentire solo le chiamate API provenienti dall'organizzazione impedisce il corretto funzionamento dello strumento di mappatura dell'origine degli eventi, pertanto `"Resource": "*"` è richiesto in queste policy. Il seguente esempio di policy degli endpoint VPC mostra come concedere l'accesso richiesto al principale del servizio Lambda per gli endpoint AWS STS e Lambda. **Example Policy dell'endpoint VPC: endpoint AWS STS** ``` { "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] } ``` **Example Policy dell'endpoint VPC: endpoint Lambda** ``` { "Statement": [ { "Action": "lambda:InvokeFunction", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] } ``` # Configurazione delle autorizzazioni del ruolo di esecuzione Lambda Oltre ad [accedere al cluster Kafka autogestito](kafka-cluster-auth.md), la funzione Lambda necessita delle autorizzazioni per eseguire varie azioni API. Aggiungere queste autorizzazioni al [ruolo di esecuzione](lambda-intro-execution-role.md) della funzione. Se i tuoi utenti devono accedere a qualsiasi azione API, aggiungi le autorizzazioni richieste alla politica di identità per l'utente o il ruolo AWS Identity and Access Management (IAM). **Topics** + [ ## Autorizzazioni necessarie per la funzione Lambda ](#smaa-api-actions-required) + [ ## Autorizzazioni facoltative per la funzione Lambda ](#smaa-api-actions-optional) + [ ## Aggiunta di autorizzazioni al ruolo di esecuzione ](#smaa-permissions-add-policy) + [ ## Concessione di accesso agli utenti con una policy IAM ](#smaa-permissions-add-users) ## Autorizzazioni necessarie per la funzione Lambda Per creare e archiviare i log in un gruppo di log in Amazon CloudWatch Logs, la funzione Lambda deve disporre delle seguenti autorizzazioni nel ruolo di esecuzione: + [registri: CreateLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html) + [registri: CreateLogStream](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogStream.html) + [registri: PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html) ## Autorizzazioni facoltative per la funzione Lambda La funzione Lambda potrebbe richiedere autorizzazioni per: + Descrivere il segreto di Secrets Manager. + Accedi alla tua chiave AWS Key Management Service (AWS KMS) gestita dal cliente. + Accedere ad Amazon VPC. + Invia i record delle chiamate non riuscite a una destinazione. ### Secrets Manager e AWS KMS autorizzazioni A seconda del tipo di controllo degli accessi che stai configurando per i tuoi broker Kafka, la tua funzione Lambda potrebbe richiedere l'autorizzazione per accedere al tuo segreto di Secrets Manager o per decrittografare la tua chiave gestita dal cliente. AWS KMS Per accedere a queste risorse, il ruolo di esecuzione della funzione deve disporre delle seguenti autorizzazioni: + [gestore dei segreti: 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) ### Autorizzazioni VPC Se soltanto gli utenti all'interno di un VPC possono accedere al cluster Apache Kafka autogestito, la funzione Lambda deve disporre dell'autorizzazione per accedere alle risorse di Amazon VPC. Queste risorse includono la VPC, le sottoreti, i gruppi di sicurezza e le interfacce di rete. Per accedere a queste risorse, il ruolo di esecuzione della funzione deve disporre delle seguenti autorizzazioni: + [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) ## Aggiunta di autorizzazioni al ruolo di esecuzione [Per accedere ad altri AWS servizi utilizzati dal cluster Apache Kafka autogestito, Lambda utilizza le politiche di autorizzazione definite nel ruolo di esecuzione della funzione Lambda.](lambda-intro-execution-role.md) Per impostazione predefinita, Lambda non è autorizzato a eseguire le operazioni richieste o facoltative per un cluster Apache Kafka autogestito. Dovrai creare e definire queste operazioni in una [policy di attendibilità IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html) per il ruolo di esecuzione. Questo esempio mostra come creare una policy che consente a Lambda di accedere alle risorse Amazon VPC. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "ec2:CreateNetworkInterface", "ec2:DescribeNetworkInterfaces", "ec2:DescribeVpcs", "ec2:DeleteNetworkInterface", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups" ], "Resource":"*" } ] } ``` ------ ## Concessione di accesso agli utenti con una policy IAM Per impostazione predefinita, gli utenti e i ruoli non dispongono dell'autorizzazione per eseguire [operazioni API di origine eventi](invocation-eventsourcemapping.md#event-source-mapping-api). Per concedere l'accesso agli utenti dell'organizzazione o dell'account, è possibile creare o aggiornare una policy basata sull'identità. *Per ulteriori informazioni, consulta [Controlling access to AWS resources using](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html) policies nella IAM User Guide.* Per la risoluzione degli errori di autenticazione e autorizzazione, consulta[Risoluzione degli errori di mappatura delle sorgenti degli eventi Kafka](with-kafka-troubleshoot.md). # Configurazione di origini eventi Apache Kafka autogestito per Lambda Per utilizzare un cluster Apache Kafka autogestito come origine di eventi per la funzione Lambda, è necessario creare una [mappatura delle sorgenti degli eventi](invocation-eventsourcemapping.md) che collega le due risorse. Questa pagina descrive come creare una mappatura delle sorgenti degli eventi per Apache Kafka autogestito. Questa pagina presuppone che tu abbia già configurato correttamente il tuo cluster Kafka e la rete in cui risiede. Se devi configurare il tuo cluster o la tua rete, vedi. [Configurazione del cluster e della rete Apache Kafka autogestiti per Lambda](with-kafka-cluster-network.md) **Topics** + [ ## Utilizzo di un cluster Apache Kafka autogestito come fonte di eventi ](#kafka-esm-overview) + [ # Configurazione dei metodi di autenticazione del cluster in Lambda ](kafka-cluster-auth.md) + [ # Creazione di una mappatura della sorgente di eventi Lambda per un'origine di eventi Apache Kafka autogestita ](kafka-esm-create.md) + [ # Tutti i parametri di configurazione dell'origine degli eventi Apache Kafka autogestiti in Lambda ](kafka-esm-parameters.md) ## Utilizzo di un cluster Apache Kafka autogestito come fonte di eventi Quando aggiungi il cluster Apache Kafka o Amazon MSK come trigger per la funzione Lambda, il cluster viene utilizzato come [origine eventi](invocation-eventsourcemapping.md). Lambda legge i dati degli eventi dagli argomenti di Kafka specificati `Topics` in una [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)richiesta, in base alla posizione [iniziale](kafka-starting-positions.md) specificata. Dopo che l'elaborazione è avvenuta con successo, l'argomento Kafka viene salvato nel cluster Kafka. Lambda legge i messaggi in sequenza per ogni partizione dell'argomento Kafka. Un singolo payload Lambda può contenere messaggi provenienti da più partizioni. Quando sono disponibili più record, Lambda continua a elaborare i record in batch, in base al BatchSize valore specificato in una [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)richiesta, finché la funzione non raggiunge l'argomento. Dopo che Lambda ha elaborato ogni batch, esegue il commit degli offset dei messaggi in quel batch. Se la funzione restituisce un errore per uno qualsiasi dei messaggi di un batch, Lambda ritenta l'intero batch di messaggi fino a quando l'elaborazione non riesce o i messaggi scadono. È possibile inviare i record per i quali tutti i nuovi tentativi falliscono a una destinazione in errore per un'elaborazione successiva. **Nota** Anche se le funzioni Lambda generalmente prevedono un timeout massimo di 15 minuti, gli strumenti di mappatura dell'origine degli eventi per Amazon MSK, Apache Kafka autogestito, Amazon DocumentDB e Amazon MQ per ActiveMQ e RabbitMQ supportano solo funzioni con timeout massimi di 14 minuti. # Configurazione dei metodi di autenticazione del cluster in Lambda Lambda supporta diversi metodi per l'autenticazione al cluster Apache Kafka autogestito. Assicurarsi di configurare il cluster Kafka in modo da utilizzare uno dei seguenti metodi di autenticazione supportati. Per ulteriori informazioni sulla sicurezza con Kafka, consultare la sezione [Sicurezza](http://kafka.apache.org/documentation.html#security) della documentazione di Kafka. ## Autenticazione SASL/SCRAM Lambda supporta l'autenticazione SASL/SCRAM (Simple Authentication and Security Layer/Salted Challenge Response Authentication Mechanism) con crittografia Transport Layer Security (TLS) (). `SASL_SSL` Lambda invia le credenziali crittografate per l'autenticazione con il cluster. Lambda non supporta il testo in SASL/SCRAM chiaro (). `SASL_PLAINTEXT` [Per ulteriori informazioni sull' SASL/SCRAM autenticazione, consulta RFC 5802.](https://tools.ietf.org/html/rfc5802) Lambda supporta SASL/PLAIN anche l'autenticazione. Poiché questo meccanismo utilizza credenziali in chiaro, la connessione al server deve utilizzare la crittografia TLS per garantire che le credenziali siano protette. Per l'autenticazione SASL, è necessario archiviare le credenziali di accesso come segreto in Gestione dei segreti AWS. Per ulteriori informazioni sull'utilizzo di Secrets Manager, consulta [Create an Gestione dei segreti AWS secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) nella *Guida Gestione dei segreti AWS per l'utente*. **Importante** Per utilizzare Secrets Manager per l'autenticazione, i segreti devono essere archiviati nella stessa AWS area della funzione Lambda. ## Autenticazione TLS reciproca MTLS (Mutual TLS) fornisce l'autenticazione bidirezionale tra client e server. Il client invia un certificato al server affinché il server verifichi il client e il server invia un certificato al client affinché il client verifichi il server. In Apache Kafka autogestito Lambda agisce come client. È possibile configurare un certificato client (come segreto in Secrets Manager) per autenticare Lambda con i broker Kafka. Il certificato client deve essere firmato da una CA nell'archivio trust del server. Il cluster Kafka invia un certificato server a Lambda per autenticare i broker con Lambda. Il certificato del server può essere un certificato CA pubblico o un certificato con CA/self-signed certificate. The public CA certificate must be signed by a certificate authority (CA) that's in the Lambda trust store. For a private CA/self firma privata, è possibile configurare il certificato CA root del server (come segreto in Secrets Manager). Lambda utilizza il certificato root per verificare i broker Kafka. Per ulteriori informazioni su mTLS, consultare [ Introduzione dell'autenticazione TLS reciproca per Amazon MSK come origine eventi](https://aws.amazon.com/blogs/compute/introducing-mutual-tls-authentication-for-amazon-msk-as-an-event-source). ## Configurazione del segreto del certificato client Il segreto CLIENT\$1CERTIFICATE\$1TLS\$1AUTH richiede un campo certificato e un campo chiave privata. Per una chiave privata crittografata, il segreto richiede una password per chiave privata. Il certificato e la chiave privata devono essere in formato PEM. **Nota** Lambda supporta gli algoritmi di crittografia a chiave privata [PBES1](https://datatracker.ietf.org/doc/html/rfc2898/#section-6.1)(ma non PBES2). Il campo certificato deve contenere un elenco di certificati, a partire dal certificato client, seguito da qualsiasi certificato intermedio, per finire con il certificato root. Ogni certificato deve iniziare su una nuova riga con la struttura seguente: ``` -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- ``` Secrets Manager supporta segreti fino a 65.536 byte, che è uno spazio sufficiente per lunghe catene di certificati. La chiave privata deve essere in formato [PKCS \$18](https://datatracker.ietf.org/doc/html/rfc5208), con la struttura seguente: ``` -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- ``` Per una chiave privata crittografata, utilizza la struttura seguente: ``` -----BEGIN ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY----- ``` Nell'esempio seguente viene mostrato il contenuto di un segreto per l'autenticazione mTLS utilizzando una chiave privata crittografata. Per una chiave privata crittografata, includere la password per chiave privata nel segreto. ``` {"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-----" } ``` ## Configurazione del segreto del certificato CA root del server Questo segreto viene creato se i broker Kafka utilizzano la crittografia TLS con certificati firmati da una CA privata. Puoi utilizzare la crittografia TLS per l'autenticazione VPC SASL/SCRAM, SASL/PLAIN o MTLS. Il segreto del certificato CA root del server richiede un campo che contiene il certificato CA root del broker Kafka in formato PEM. Il seguente esempio illustra la struttura del segreto. ``` {"certificate":"-----BEGIN CERTIFICATE----- MIID7zCCAtegAwIBAgIBADANBgkqhkiG9w0BAQsFADCBmDELMAkGA1UEBhMCVVMx EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAjBgNVBAoT HFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xOzA5BgNVBAMTMlN0YXJmaWVs ZCBTZXJ2aWNlcyBSb290IENlcnRpZmljYXRlIEF1dG... -----END CERTIFICATE-----" } ``` # Creazione di una mappatura della sorgente di eventi Lambda per un'origine di eventi Apache Kafka autogestita [Per creare una mappatura delle sorgenti degli eventi, puoi utilizzare la console Lambda, la [AWS Command Line Interface (CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)) o un SDK.AWS](https://aws.amazon.com/getting-started/tools-sdks/) I seguenti passaggi della console aggiungono un cluster Apache Kafka autogestito come trigger per la funzione Lambda. Sotto il cofano, questo crea una risorsa di mappatura delle sorgenti degli eventi. ## Prerequisiti + Un cluster Apache Kafka autogestito. Lambda supporta la versione 0.10.1.0 e successive di Apache Kafka. + Un [ruolo di esecuzione](lambda-intro-execution-role.md) con autorizzazione ad accedere alle AWS risorse utilizzate dal cluster Kafka autogestito. ## Aggiunta di un cluster Kafka autogestito (console) Segui questi passaggi per aggiungere il cluster Apache Kafka autogestito e un argomento Kafka come trigger per la funzione Lambda. **Per aggiungere un trigger Apache Kafka alla funzione Lambda (console)** 1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda. 1. Scegliere il nome della funzione Lambda. 1. In **Panoramica delle funzioni**, scegliere **Aggiungi trigger**. 1. In **Configurazione trigger**, effettua le operazioni seguenti: 1. Scegliere il tipo di trigger **Apache Kafka**. 1. Per **Server di bootstrap**, inserisci l'indirizzo composto dalla coppia host e porta di un broker Kafka nel cluster, quindi scegli **Aggiungi**. Ripeti la procedura per ogni broker Kafka del cluster. 1. Per **Nome argomento**, inserisci il nome dell'argomento Kafka utilizzato per memorizzare i record nel cluster. 1. Se configuri la modalità provisioned, inserisci un valore per **Minimum event poller**, un valore per **Maximum event poller** e un valore opzionale per PollerGroupName specificare il raggruppamento di più eventi ESMs all'interno dello stesso VPC di origine eventi. 1. (Facoltativo) In **Dimensioni batch**, inserisci il numero massimo di record da ricevere in un singolo batch. 1. Per **Finestra batch**, immetti il tempo massimo in secondi per la raccolta dei registri da parte di Lambda prima di richiamare la funzione. 1. (Facoltativo) Per **ID gruppo di consumer**, inserisci l'ID di un gruppo di consumer Kafka a cui aderire. 1. (Facoltativo) Per **Posizione di inizio**, scegli **Più recente** per iniziare a leggere il flusso dal record più recente, **Orizzonte di taglio** per iniziare dal primo record disponibile o **In corrispondenza del timestamp** per specificare un timestamp da cui iniziare la lettura. 1. (Facoltativo) Per **VPC**, scegli Amazon VPC per il cluster Kafka. Quindi, scegli **Sottoreti VPC** e **Gruppi di sicurezza VPC**. Questa impostazione è necessaria soltanto se gli utenti del VPC accedono ai broker. 1. (Facoltativo) Per **Autenticazione**, scegli **Aggiungi** e quindi esegui le seguenti operazioni: 1. Scegli il protocollo di accesso o di autenticazione dei broker Kafka del cluster. + **Se il tuo broker Kafka utilizza l'autenticazione, scegli BASIC\$1AUTH. SASL/PLAIN ** + Se il tuo broker utilizza SASL/SCRAM l'autenticazione, scegli uno dei protocolli. **SASL\$1SCRAM** + Se stai configurando l'autenticazione mTLS, scegli il protocollo **CLIENT\$1CERTIFICATE\$1TLS\$1AUTH**. 1. Per SASL/SCRAM l'autenticazione MTLS, scegli la chiave segreta Secrets Manager che contiene le credenziali per il tuo cluster Kafka. 1. (Facoltativo) Per **Crittografia**, scegli il segreto di Secrets Manager contenente il certificato CA root utilizzato dai broker Kafka per la crittografia TLS, se i broker Kafka utilizzano certificati firmati da una CA privata. Questa impostazione si applica alla crittografia TLS per SASL/PLAIN e all' SASL/SCRAM autenticazione MTLS. 1. Per creare il trigger in uno stato disabilitato per il test (scelta consigliata), deselezionare **Abilita trigger**. Oppure, per attivare immediatamente il trigger, selezionare**Abilita trigger**. 1. Per creare il trigger, scegli **Aggiungi**. ## Aggiunta di un cluster Kafka autogestito (AWS CLI) Usa i seguenti AWS CLI comandi di esempio per creare e visualizzare un trigger Apache Kafka autogestito per la tua funzione Lambda. ### Utilizzo di SASL/SCRAM Se gli utenti Kafka accedono ai tuoi broker Kafka tramite Internet, specifica il segreto Secrets Manager che hai creato per l'autenticazione. SASL/SCRAM L'esempio seguente utilizza il [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI comando per mappare una funzione Lambda denominata `my-kafka-function` a un argomento di Kafka denominato. `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"]}}' ``` ### Utilizzo di un VPC Se solo gli utenti Kafka all'interno del proprio VPC accedono ai broker Kafka, dovrai specificare VPC, sottorete e gruppo di sicurezza del VPC. L'esempio seguente utilizza il [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI comando per mappare una funzione Lambda denominata `my-kafka-function` a un argomento di Kafka denominato. `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"]}}' ``` ### Visualizzazione dello stato utilizzando il AWS CLI L'esempio seguente utilizza il [get-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-event-source-mapping.html) AWS CLI comando per descrivere lo stato della mappatura dell'origine degli eventi creata. ``` aws lambda get-event-source-mapping --uuid dh38738e-992b-343a-1077-3478934hjkfd7 ``` # Tutti i parametri di configurazione dell'origine degli eventi Apache Kafka autogestiti in Lambda Tutti i tipi di sorgenti di eventi Lambda condividono le stesse operazioni [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)e quelle dell'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)API. Tuttavia, solo alcuni parametri si applicano ad Apache Kafka autogestito, come illustrato nella tabella seguente. | Parametro | Obbligatorio | Predefinito | Note | | --- | --- | --- | --- | | BatchSize | N | 100 | Massimo: 10.000. | | DestinationConfig | N | N/D | [Acquisizione di batch scartati per un'origine eventi di Amazon MSK e Apache Kafka autogestito](kafka-on-failure.md) | | Abilitato | N | True | | | FilterCriteria | N | N/D | [Controllare gli eventi che Lambda invia alla funzione](invocation-eventfiltering.md) | | FunctionName | Y | N/D | | | KMSKeyArn | N | N/D | [Crittografia dei criteri di filtro](invocation-eventfiltering.md#filter-criteria-encryption) | | MaximumBatchingWindowInSeconds | N | 500 ms | [Comportamento di batching](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching) | | ProvisionedPollersConfig | N | `MinimumPollers`: se non specificato, il valore predefinito è 1 `MaximumPollers`: se non specificato, il valore predefinito è 200 `PollerGroupName`: N/A | [Modalità provisioning](kafka-scaling-modes.md#kafka-provisioned-mode) | | SelfManagedEventSource | Y | N/D | Elenco dei broker Kafka. Può essere impostato solo su Create | | SelfManagedKafkaEventSourceConfig | N | Contiene il ConsumerGroupId campo che per impostazione predefinita è un valore univoco. | Può essere impostato solo su Create | | SourceAccessConfigurations | N | Nessuna credenziale | Informazioni sul VPC o credenziali di autenticazione per il cluster Per SASL\$1PLAIN, imposta su BASIC\$1AUTH | | StartingPosition | Y | N/D | AT\$1TIMESTAMP, TRIM\$1HORIZON o LATEST Può essere impostato solo su Create | | StartingPositionTimestamp | N | N/D | Obbligatorio se StartingPosition è impostato su AT\$1TIMESTAMP | | Tag | N | N/D | [Utilizzo di tag negli strumenti di mappatura dell'origine degli eventi](tags-esm.md) | | Argomenti | Y | N/D | Nome dell'argomento Può essere impostato solo su Create | **Nota** Quando si specifica una`PollerGroupName`, più unità ESMs all'interno dello stesso Amazon VPC possono condividere la capacità dell'Event Poller Unit (EPU). Puoi utilizzare questa opzione per ottimizzare i costi della modalità Provisioned per i tuoi. ESMs Requisiti per il raggruppamento ESM: ESMs deve trovarsi all'interno dello stesso Amazon VPC Massimo 100 ESMs per gruppo di sondaggi Il numero massimo aggregato di sondaggi di tutti ESMs i membri di un gruppo non può superare i 2000 È possibile aggiornare il file `PollerGroupName` per spostare un ESM in un gruppo diverso oppure rimuovere un ESM da un gruppo `PollerGroupName` impostandolo su una stringa vuota («»).