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à.
Configurazione delle sorgenti di eventi Apache Kafka autogestite per Lambda
Prima di creare una mappatura delle sorgenti degli eventi per il cluster Apache Kafka autogestito, devi assicurarti che il cluster e il relativo cluster siano configurati correttamente. VPC È inoltre necessario assicurarsi che il ruolo di esecuzione della funzione Lambda disponga delle autorizzazioni necessarieIAM.
Segui le istruzioni nelle sezioni seguenti per configurare il cluster Apache Kafka autogestito e la funzione Lambda. Per informazioni su come creare la mappatura delle sorgenti degli eventi, consulta. Aggiunta di un cluster Kafka come origine eventi
Argomenti
Autenticazione cluster Kafka
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
VPCaccesso
Se solo gli utenti Kafka all'interno del tuo account VPC accedono ai tuoi broker Kafka, devi configurare la fonte di eventi Kafka per l'accesso ad Amazon Virtual Private Cloud (Amazon). VPC
SASL/autenticazione SCRAM
Lambda supporta l'autenticazione Simple Authentication and Security Layer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM) con crittografia Transport Layer Security () (TLS). SASL_SSL Lambda invia le credenziali crittografate per l'autenticazione con il cluster. Lambda non supportaSASL/SCRAMcon testo in chiaro (). SASL_PLAINTEXT Per ulteriori informazioni suSASL/SCRAMauthentication, consulta 5802. RFC
Lambda supporta anche l'autenticazione SASL PLAIN /. Poiché questo meccanismo utilizza credenziali in chiaro, la connessione al server deve utilizzare la TLS crittografia per garantire che le credenziali siano protette.
Per SASL l'autenticazione, le credenziali di accesso vengono archiviate come accesso segreto. AWS Secrets Manager Per ulteriori informazioni sull'uso di Secrets Manager, consultare Tutorial: Creare e recuperare un segreto nella Guida per l'utente AWS Secrets Manager .
Importante
Per utilizzare Secrets Manager per l'autenticazione, i segreti devono essere archiviati nella stessa AWS area della funzione Lambda.
Autenticazione reciproca TLS
Mutual TLS (mTLS) 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 CA/autofirmato privato. Il certificato emesso da una CA pubblica deve essere firmato da un'autorità di certificazione (CA) presente nel trust store di Lambda. Per un certificato CA/autofirmato privato, è 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, consulta Introducing mutual TLS authentication for Amazon MSK as an event source
Configurazione del segreto del certificato client
Il AUTH segreto CLIENT CERTIFICATE _ TLS _ _ richiede un campo certificato e un campo chiave privata. Per una chiave privata crittografata, il segreto richiede una password per chiave privata. Sia il certificato che la chiave privata devono essere in PEM formato.
Nota
Lambda supporta gli algoritmi di crittografia a chiave privata PBES1
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----- <certificate contents> -----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#8
-----BEGIN PRIVATE KEY----- <private key contents> -----END PRIVATE KEY-----
Per una chiave privata crittografata, utilizza la struttura seguente:
-----BEGIN ENCRYPTED PRIVATE KEY----- <private key contents> -----END ENCRYPTED PRIVATE KEY-----
L'esempio seguente mostra il contenuto di un segreto per la mia TLS autenticazione 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 TLS crittografia con certificati firmati da una CA privata. È possibile utilizzare TLS la crittografia per l'VPCautenticazione,SASL/SCRAMPLAIN,SASL/o m. TLS
Il segreto del certificato CA principale del server richiede un campo che contenga il certificato CA principale del broker Kafka in PEM formato. Il seguente esempio illustra la struttura del segreto.
{"certificate":"-----BEGIN CERTIFICATE----- MIID7zCCAtegAwIBAgIBADANBgkqhkiG9w0BAQsFADCBmDELMAkGA1UEBhMCVVMx EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAjBgNVBAoT HFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xOzA5BgNVBAMTMlN0YXJmaWVs ZCBTZXJ2aWNlcyBSb290IENlcnRpZmljYXRlIEF1dG... -----END CERTIFICATE-----" }
Configurazione della rete
Affinché Lambda utilizzi il cluster Kafka come origine di eventi, Lambda deve accedere all'Amazon VPC in cui risiede il cluster. Ti consigliamo di implementare AWS PrivateLink VPCendpoint per Lambda per accedere a. VPC Distribuisci endpoint per Lambda e (). AWS Security Token Service AWS STS Se il broker utilizza l'autenticazione, implementa anche un VPC endpoint per Secrets Manager. Se hai configurato una destinazione in caso di errore, implementa anche un VPC endpoint per il servizio di destinazione.
In alternativa, assicurati che il cluster Kafka VPC associato al tuo cluster Kafka includa un NAT gateway per sottorete pubblica. Per ulteriori informazioni, consulta Abilita l'accesso a Internet per le funzioni VPC Lambda connesse.
Se utilizzi gli VPC endpoint, devi anche configurarli per abilitare i nomi privati. DNS
Quando crei una mappatura dell'origine degli eventi per un cluster Apache Kafka autogestito, Lambda verifica se Elastic Network Interfaces ENIs () sono già presenti per le sottoreti e i gruppi di sicurezza del tuo cluster. VPC Se Lambda rileva che esistonoENIs, tenta di riutilizzarli. Altrimenti, Lambda ne crea di nuovi ENIs per connettersi all'origine dell'evento e richiamare la funzione.
Nota
Le funzioni Lambda vengono sempre eseguite all'interno del servizio Lambda di VPCs proprietà. Queste VPCs vengono gestite automaticamente dal servizio e non sono visibili ai clienti. Puoi anche collegare la tua funzione a un AmazonVPC. In entrambi i casi, la VPC configurazione della funzione non influisce sulla mappatura della fonte degli eventi. Solo la configurazione dell'origine dell'evento VPC determina il modo in cui Lambda si connette all'origine dell'evento.
Per ulteriori informazioni sulla configurazione della rete, consulta Configurazione AWS Lambda con un cluster Apache Kafka all'interno di un VPC
VPCregole dei gruppi di sicurezza
Configura i gruppi di sicurezza per l'Amazon VPC che contiene il tuo cluster con le seguenti regole (come minimo):
-
Regole in entrata – Consenti tutto il traffico sulla porta del broker Kafka per i gruppi di sicurezza specificati per l'origine eventi. Kafka utilizza la porta 9092 per impostazione predefinita.
-
Regole in uscita: consenti tutto il traffico sulla porta 443 per tutte le destinazioni. Consenti tutto il traffico sulla porta del broker Kafka per i gruppi di sicurezza specificati per l'origine eventi. Kafka utilizza la porta 9092 per impostazione predefinita.
-
Se utilizzi gli VPC endpoint anziché un NAT gateway, i gruppi di sicurezza associati agli VPC endpoint devono consentire tutto il traffico in entrata sulla porta 443 proveniente dai gruppi di sicurezza dell'origine dell'evento.
Utilizzo degli endpoint VPC
Quando si utilizzano gli VPC endpoint, API le chiamate per richiamare la funzione vengono instradate attraverso questi endpoint utilizzando il. ENIs Il responsabile del servizio Lambda deve chiamare sts:AssumeRole e lambda:InvokeFunction attivare tutti i ruoli e le funzioni che li utilizzano. ENIs
Per impostazione predefinita, VPC gli endpoint dispongono IAM di policy aperte. La migliore pratica consiste nel limitare queste politiche per consentire solo a soggetti specifici di eseguire le azioni necessarie utilizzando quell'endpoint. Per garantire che la mappatura delle sorgenti degli eventi sia in grado di richiamare la funzione Lambda, la policy degli VPC endpoint deve consentire al principio del servizio Lambda di chiamare e. sts:AssumeRole lambda:InvokeFunction La limitazione delle policy VPC degli endpoint per consentire solo le API chiamate provenienti dall'organizzazione impedisce il corretto funzionamento della mappatura delle sorgenti degli eventi.
I seguenti esempi di policy VPC sugli endpoint mostrano come concedere l'accesso richiesto al principale del servizio Lambda per gli endpoint Lambda AWS STS e Lambda.
Esempio VPCpolitica degli endpoint - endpoint AWS STS
{ "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] }
Esempio VPCpolitica degli endpoint - Lambda endpoint
{ "Statement": [ { "Action": "lambda:InvokeFunction", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] }
Se il tuo broker Kafka utilizza l'autenticazione, puoi anche limitare la policy degli endpoint per l'VPCendpoint Secrets Manager. Per chiamare Secrets ManagerAPI, Lambda utilizza il ruolo della funzione, non il responsabile del servizio Lambda. L'esempio seguente mostra una policy per gli endpoint di Secrets Manager.
Esempio VPCpolitica degli endpoint - Endpoint Secrets Manager
{ "Statement": [ { "Action": "secretsmanager:GetSecretValue", "Effect": "Allow", "Principal": { "AWS": [ "customer_function_execution_role_arn" ] }, "Resource": "customer_secret_arn" } ] }
Se hai configurato una destinazione in caso di errore, Lambda utilizza anche il ruolo della tua funzione per chiamare una sqs:sendMessage o l's3:PutObjectaltra sns:Publish destinazione gestita da Lambda. ENIs
APIpermessi di accesso e delle funzioni Lambda
Oltre ad accedere al cluster Kafka autogestito, la funzione Lambda necessita delle autorizzazioni per eseguire varie azioni. API Aggiungere queste autorizzazioni al ruolo di esecuzione della funzione. Se gli utenti devono accedere a qualsiasi API azione, aggiungi le autorizzazioni richieste alla politica di identità per l'utente o il ruolo (). AWS Identity and Access Management IAM
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:
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.
-
Accedi al tuo AmazonVPC.
-
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:
VPCautorizzazioni
Se solo gli utenti all'interno di un VPC possono accedere al tuo cluster Apache Kafka autogestito, la tua funzione Lambda deve avere l'autorizzazione per accedere alle tue risorse Amazon. VPC Queste risorse includono le tue sottoretiVPC, 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:
Aggiunta di autorizzazioni al ruolo di esecuzione
Per impostazione predefinita, Lambda non è autorizzato a eseguire le operazioni richieste o facoltative per un cluster Apache Kafka autogestito. È necessario creare e definire queste azioni in una politica di fiducia per il ruolo di IAM esecuzione. Questo esempio mostra come potresti creare una policy che consenta Lambda di accedere alle tue risorse AmazonVPC.
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "ec2:CreateNetworkInterface", "ec2:DescribeNetworkInterfaces", "ec2:DescribeVpcs", "ec2:DeleteNetworkInterface", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups" ], "Resource":"*" } ] }
Concedere agli utenti l'accesso con una policy IAM
Per impostazione predefinita, gli utenti e i ruoli non dispongono dell'autorizzazione per eseguire APIoperazioni sull'origine degli eventi. Per concedere l'accesso agli utenti dell'organizzazione o dell'account, è possibile creare o aggiornare una policy basata sull'identità. Per ulteriori informazioni, vedere Controllo dell'accesso alle AWS risorse mediante le politiche nella Guida per l'IAMutente.
