Configurazione delle sorgenti di MSK eventi Amazon per Lambda

Prima di creare una mappatura delle sorgenti degli eventi per il tuo MSK cluster Amazon, devi assicurarti che il cluster e il cluster in cui VPC risiede siano configurati correttamente. È inoltre necessario assicurarsi che il ruolo di esecuzione della funzione Lambda disponga delle autorizzazioni necessarieIAM.

Segui le istruzioni nelle seguenti sezioni per configurare il tuo MSK cluster Amazon e VPC la funzione Lambda. Per informazioni su come creare la mappatura delle sorgenti degli eventi, consulta. Aggiungere Amazon MSK come fonte di eventi

MSKautenticazione del cluster

Lambda necessita dell'autorizzazione per accedere al MSK cluster Amazon, recuperare i record ed eseguire altre attività. Amazon MSK supporta diverse opzioni per controllare l'accesso dei client al MSK cluster.

Accesso non autenticato

Se nessun client accede al cluster tramite Internet, è possibile utilizzare l'accesso non autenticato.

SASL/SCRAMautenticazione

Amazon MSK supporta l'autenticazione Simple Authentication and Security Layer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM) con crittografia Transport Layer Security (TLS). Per consentire a Lambda di connettersi al cluster, è necessario archiviare le credenziali di autenticazione (nome utente e password) in un luogo segreto. AWS Secrets Manager

Per ulteriori informazioni sull'uso di Secrets Manager, consulta Autenticazione nome utente e password con AWS Secrets Manager nella Guida per gli sviluppatori di Amazon Managed Streaming for Apache Kafka.

Amazon MSK non supporta PLAIN l'autenticazione SASL /.

Autenticazione basata su ruoli IAM

Puoi utilizzarla IAM per autenticare l'identità dei client che si connettono al MSK cluster. Se IAM l'autenticazione è attiva nel MSK cluster e non fornisci un segreto per l'autenticazione, Lambda utilizza automaticamente l'autenticazione per impostazione predefinita. IAM Per creare e distribuire policy basate sugli utenti o sui ruoli, usa la console o. IAM API Per ulteriori informazioni, consulta il controllo degli IAM accessi nella Amazon Managed Streaming for Apache Kafka Developer Guide.

Per consentire a Lambda di connettersi al MSK cluster, leggere i record ed eseguire altre azioni richieste, aggiungi le seguenti autorizzazioni al ruolo di esecuzione della tua funzione.

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

È possibile assegnare queste autorizzazioni a un cluster, un argomento e un gruppo specifici. Per ulteriori informazioni, consulta le azioni di Amazon MSK Kafka nella Amazon Managed Streaming for Apache Kafka Developer Guide.

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.

Per AmazonMSK, Lambda funge da client. Configurate un certificato client (come segreto in Secrets Manager) per autenticare Lambda con i broker del vostro cluster. MSK Il certificato client deve essere firmato da una CA nell'archivio trust del server. Il MSK cluster invia un certificato del server a Lambda per autenticare i broker con Lambda. Il certificato del server deve essere firmato da un'autorità di certificazione (CA) presente nel trust store. AWS

Per istruzioni su come generare un certificato client, consulta Introduzione dell'TLSautenticazione reciproca per Amazon MSK come fonte di eventi.

Amazon MSK non supporta i certificati server autofirmati, perché tutti i broker di Amazon MSK utilizzano certificati pubblici firmati da Amazon Trust Services CAs, che Lambda considera affidabili per impostazione predefinita.

Per ulteriori informazioni su m TLS for AmazonMSK, consulta Mutual TLS Authentication nella Amazon Managed Streaming for Apache Kafka Developer Guide.

Configurazione di m secret TLS

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.

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, con la seguente struttura:

-----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, includi una 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-----"
} 

Come Lambda sceglie un broker bootstrap

Lambda sceglie un broker bootstrap in base ai metodi di autenticazione disponibili nel tuo cluster e se fornisci un segreto per l'autenticazione. Se fornisci un segreto per m TLS oSASL/SCRAM, Lambda sceglie automaticamente quel metodo di autenticazione. Se non fornisci un segreto, Lambda seleziona il metodo di autenticazione più forte attivo sul tuo cluster. Di seguito è riportato l'ordine di priorità in cui Lambda seleziona un broker, dall'autenticazione più forte a quella più debole:

Gestione API degli accessi e delle autorizzazioni

Oltre ad accedere al MSK cluster Amazon, la tua funzione necessita delle autorizzazioni per eseguire varie MSK API azioni Amazon. Aggiungi queste autorizzazioni al ruolo di esecuzione della funzione. Se i tuoi utenti devono accedere a una qualsiasi delle MSK API azioni Amazon, aggiungi le autorizzazioni richieste alla politica di identità per l'utente o il ruolo.

Puoi aggiungere manualmente ciascuna delle seguenti autorizzazioni al tuo ruolo di esecuzione. In alternativa, puoi allegare la policy AWS gestita AWSLambdaMSKExecutionRoleal tuo ruolo di esecuzione. La AWSLambdaMSKExecutionRole policy contiene tutte le API azioni e le VPC autorizzazioni richieste elencate di seguito.

Autorizzazioni del ruolo di esecuzione della funzione Lambda necessarie

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:

Affinché Lambda possa accedere al tuo MSK cluster Amazon per tuo conto, la funzione Lambda deve disporre delle seguenti autorizzazioni nel suo ruolo di esecuzione:

Devi solo aggiungere uno dei seguenti: kafka:DescribeCluster o kafka:DescribeClusterV2. Per i MSK cluster con provisioning, entrambe le autorizzazioni funzionano. Per i MSK cluster serverless, è necessario utilizzare. kafka:DescribeClusterV2

VPCautorizzazioni

Se solo gli utenti all'interno di un VPC possono accedere al tuo MSK cluster Amazon, la tua funzione Lambda deve avere l'autorizzazione per accedere alle tue risorse AmazonVPC. 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. Queste autorizzazioni sono incluse nella politica AWSLambdaMSKExecutionRole AWS gestita.

Autorizzazioni facoltative per la funzione Lambda

La funzione Lambda potrebbe richiedere autorizzazioni per:

Secrets Manager e AWS KMS autorizzazioni

A seconda del tipo di controllo degli accessi che stai configurando per i tuoi MSK broker Amazon, la tua funzione Lambda potrebbe aver bisogno dell'autorizzazione per accedere al tuo SCRAM segreto (se usiSASL/SCRAMauthentication) o al segreto di Secrets Manager per decrittografare la chiave gestita dal cliente. AWS KMS Per accedere a queste risorse, il ruolo di esecuzione della funzione deve disporre delle seguenti autorizzazioni:

Aggiunta di autorizzazioni al ruolo di esecuzione

Segui questi passaggi per aggiungere la policy AWS gestita AWSLambdaMSKExecutionRoleal tuo ruolo di esecuzione utilizzando la IAM console.

Concedere agli utenti l'accesso tramite una policy IAM

Per impostazione predefinita, gli utenti e i ruoli non dispongono dell'autorizzazione per eseguire MSK API operazioni Amazon. Per concedere l'accesso agli utenti dell'organizzazione o dell'account, è possibile aggiungere una policy basata sull'identità. Per ulteriori informazioni, consulta gli esempi di policy MSK basate sull'identità di Amazon nella Amazon Managed Streaming for Apache Kafka Developer Guide.

Errori di autenticazione e autorizzazione

Se manca una delle autorizzazioni necessarie per consumare i dati dal MSK cluster Amazon, Lambda visualizza uno dei seguenti messaggi di errore nella mappatura dell'origine degli eventi sotto. LastProcessingResult

Il cluster non è riuscito ad autorizzare Lambda

PerSASL/SCRAMo mTLS, questo errore indica che l'utente fornito non dispone di tutte le seguenti autorizzazioni necessarie per Kafka access control list (): ACL

Per il controllo degli IAM accessi, al ruolo di esecuzione della funzione mancano una o più delle autorizzazioni necessarie per accedere al gruppo o all'argomento. Rivedi l'elenco delle autorizzazioni richieste in Autenticazione basata su ruoli IAM.

Quando crei Kafka ACLs o una IAM politica con le autorizzazioni richieste per il cluster Kafka, specifica l'argomento e il gruppo come risorse. Il nome dell'argomento deve corrispondere all'argomento nella mappatura dell'origine eventi. Il nome del gruppo deve corrispondere a quello della mappatura della fonte dell'evento. UUID

Dopo avere aggiunto le autorizzazioni richieste al ruolo di esecuzione, potrebbero essere necessari alcuni minuti affinché le modifiche entrino in vigore.

SASLautenticazione non riuscita

PerSASL/SCRAM, questo errore indica che il nome utente e la password forniti non sono validi.

Per il controllo degli IAM accessi, al ruolo di esecuzione manca l'kafka-cluster:Connectautorizzazione per il MSK cluster. Aggiungi questa autorizzazione al ruolo e specifica l'Amazon Resource Name (ARN) del cluster come risorsa.

Potresti visualizzare questo errore in modo intermittente. Il cluster rifiuta le connessioni dopo che il numero di TCP connessioni supera la quota di MSKservizio Amazon. Lambda cessa e ritenta finché una connessione non ha esito positivo. Dopo che Lambda si connette al cluster e ha eseguito il polling dei registri, l'ultimo risultato di elaborazione cambia in OK.

Il server non è riuscito ad autenticare Lambda

Questo errore indica che i broker Amazon MSK Kafka non sono riusciti ad autenticarsi con Lambda. Questo errore può verificarsi per uno dei seguenti motivi:

Il certificato o la chiave privata forniti non sono validi

Questo errore indica che il MSK consumatore Amazon non ha potuto utilizzare il certificato o la chiave privata forniti. Assicurati che il certificato e la chiave utilizzino il PEM formato e che la crittografia a chiave privata utilizzi un PBES1 algoritmo.

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 MSK cluster, Lambda verifica se Elastic Network Interfaces ENIs () sono già presenti per le sottoreti e i gruppi di sicurezza del 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.

La tua VPC configurazione Amazon è rilevabile tramite Amazon MSK API. Non è necessario configurarlo durante l'installazione utilizzando il comando create-event-source-mapping.

Per ulteriori informazioni sulla configurazione della rete, consulta Configurazione AWS Lambda con un cluster Apache Kafka all'interno di un VPC blog su Compute. AWS

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):

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.

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

{
    "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.

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