Configurazione delle origini eventi di Amazon MSK per Lambda

Prima di creare uno strumento di mappatura dell'origine degli eventi per il tuo cluster Amazon MSK, devi assicurarti che il cluster e il VPC in cui si trova siano configurati correttamente. È inoltre necessario assicurarsi che il ruolo di esecuzione della funzione Lambda disponga delle autorizzazioni IAM necessarie.

Segui le istruzioni nelle seguenti sezioni per configurare il cluster Amazon MSK, il VPC e la funzione Lambda. Per informazioni su come creare lo strumento di mappatura dell'origine degli eventi, consulta Aggiunta di Amazon MSK come origine eventi.

Autenticazione cluster MSK

Lambda ha bisogno dell'autorizzazione per accedere al cluster Amazon MSK, recuperare registri ed eseguire altri processi. Amazon MSK supporta diverse opzioni per il controllo dell'accesso del client al cluster MSK.

Accesso non autenticato

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

Autenticazione SASL/SCRAM

Amazon MSK supporta l'autenticazione SASL/SCRAM (Simple Authentication and Security Layer/Salted Challenge Response Authentication Mechanism) con crittografia Transport Layer Security (TLS). Per consentire la connessione di Lambda al cluster, è necessario archiviare le credenziali di autenticazione (nome utente e password) in un 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 l'autenticazione SASL/PLAIN.

Autenticazione basata su ruoli IAM

È possibile utilizzare IAM per autenticare l'identità dei client che si connettono al cluster MSK. Se l'autenticazione IAM è attiva sul tuo cluster MSK e non fornisci un segreto per l'autenticazione, Lambda utilizza automaticamente l'autenticazione IAM. Per creare e implementare policy basate su utenti o ruoli, utilizza l'API o la console IAM. Per ulteriori informazioni, consulta il controllo accessi IAM nella Guida per sviluppatori Amazon Managed Streaming for Apache Kafka.

Per consentire a Lambda di connettersi al cluster MSK, leggere i registri ed eseguire altre operazioni richieste, aggiungere le seguenti autorizzazioni al ruolo di esecuzione della 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 operazioni Kafka di Amazon MSK nella Guida per sviluppatori Amazon Managed Streaming for Apache Kafka.

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.

Per Amazon MSK, Lambda funge da cliente. È possibile configurare un certificato client (come segreto in Secrets Manager) per autenticare Lambda con i broker nel cluster MSK. Il certificato client deve essere firmato da una CA nell'archivio trust del server. Il cluster MSK invia un certificato server a Lambda per autenticare i broker con Lambda. Il certificato 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'autenticazione TLS reciproca per Amazon MSK come origine eventi.

Amazon MSK non supporta i certificati server autofirmati poiché tutti i broker di Amazon MSK utilizzano certificati pubblici firmati dalle autorità di certificazione di Amazon Trust Services, su cui Lambda fa affidamento per impostazione predefinita.

Per ulteriori informazioni, su mTLS per Amazon MSK, consulta Autenticazione TLS reciproca nella Guida per sviluppatori Amazon Managed Streaming for Apache Kafka.

Configurazione del segreto mTLS

Il segreto CLIENT_CERTIFICATE_TLS_AUTH 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.

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 struttura seguente:

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

Nell'esempio seguente viene mostrato il contenuto di un segreto per l'autenticazione mTLS 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 mTLS o SASL/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 dell'accesso e delle autorizzazioni API

Oltre ad accedere al cluster Amazon MSK, la funzione necessita di autorizzazioni per eseguire varie operazioni dell'API Amazon MSK. Aggiungi queste autorizzazioni al ruolo di esecuzione della funzione. Se gli utenti hanno bisogno di accedere a una qualsiasi delle operazioni dell'API Amazon MSK, aggiungi le autorizzazioni richieste alla policy di identità per l'utente o il ruolo.

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

Autorizzazioni del ruolo di esecuzione della funzione Lambda necessarie

Per creare e memorizzare log in un gruppo di log in Amazon CloudWatch Logs, la funzione Lambda deve disporre delle seguenti autorizzazioni nel suo ruolo di esecuzione:

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

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

Autorizzazioni VPC

Se solo gli utenti all'interno di un VPC possono accedere al cluster Amazon MSK, la funzione Lambda deve disporre dell'autorizzazione ad 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. Queste autorizzazioni sono incluse nella policy gestita da AWS AWSLambdaVPCAccessExecutionRole.

Autorizzazioni facoltative per la funzione Lambda

La funzione Lambda potrebbe richiedere autorizzazioni per:

Secrets Manager e autorizzazioni AWS KMS

A seconda del tipo di controllo degli accessi configurato per i broker Amazon MSK, la funzione Lambda potrebbe richiedere l'autorizzazione ad accedere al segreto SCRAM (se utilizzi l'autenticazione SASL/SCRAM) o al segreto di Secret Manager per decrittare 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

Completa la seguente procedura per aggiungere la policy gestita da AWS AWSLambdaMSKExecutionRole al ruolo di esecuzione utilizzando la console IAM.

Concessione di accesso agli utenti con una policy IAM

Per impostazione predefinita, gli utenti e i ruoli non sono autorizzati a eseguire le operazioni API Amazon MSK. Per concedere l'accesso agli utenti dell'organizzazione o dell'account, è possibile aggiungere una policy basata sull'identità. Per ulteriori informazioni, consulta Esempi di policy basate sull'identità Amazon MSK nella Guida per gli sviluppatori di Amazon Managed Streaming for Apache Kafka.

Errori di autenticazione e autorizzazione

Se manca una delle autorizzazioni necessarie per l'utilizzo dei dati dal cluster Amazon MSK, Lambda visualizza un messaggio di errore nella mappatura dell'origine eventi in LastProcessingResult.

Il cluster non è riuscito ad autorizzare Lambda

Per SASL/SCRAM o mTLS, questo errore indica che l'utente fornito non dispone di tutte le seguenti autorizzazioni della lista di controllo accessi Kafka (ACL) richieste:

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

Quando si creano ACL Kafka o una policy IAM con le autorizzazioni del cluster Kafka richieste, è necessario specificare 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 all'UUID della mappatura dell'origine eventi.

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

Autenticazione SASL non riuscita

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

Per il controllo accessi IAM, al ruolo di esecuzione manca l'autorizzazione kafka-cluster:Connect per il cluster MSK. 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 connessioni TCP supera la quota del servizio Amazon MSK. 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 consumatore Amazon MSK non ha potuto utilizzare il certificato o la chiave privata forniti. Assicurati che il certificato e la chiave utilizzino il formato PEM e che la crittografia della chiave privata utilizzi un algoritmo PBES1.

Configurare la sicurezza della rete

Per concedere a Lambda l'accesso completo ad Amazon MSK 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 Amazon MSK con Lambda, crea endpoint VPC AWS PrivateLink che forniscono alla funzione l'accesso alle risorse del tuo Amazon VPC.

Crea un endpoint per fornire l'accesso alle seguenti risorse:

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.

Quando crei uno strumento di mappatura dell'origine degli eventi per Amazon MSK, 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.

Configura i gruppi di sicurezza per l'Amazon VPC contenente il tuo cluster. Per impostazione predefinita, Amazon MSK utilizza le seguenti porte: 9092 per testo semplice, 9094 per TLS, 9096 per SASL, 9098 per IAM.

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.

{
      "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 richiamare la funzione utilizzando l'interfaccia di rete elastica (ENI) dell'endpoint. Il principale del servizio Lambda deve richiamare lambda:InvokeFunction 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 richiamare 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.

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

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