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 dei metodi di autenticazione del cluster in Lambda
Lambda necessita dell'autorizzazione per accedere al cluster Amazon MSK, recuperare record ed eseguire altre attività. Amazon MSK supporta diversi modi per l'autenticazione con il cluster MSK.
Metodi di autenticazione del cluster
Accesso non autenticato
Se nessun client accede al cluster tramite Internet, è possibile utilizzare l'accesso non autenticato.
Autenticazione SASL/SCRAM
Lambda supporta l'autenticazione SASL/SCRAM (Simple Authentication and Security Layer/Salted Challenge Response Authentication Mechanism), con la funzione hash SHA-512 e la crittografia Transport Layer Security (TLS). Affinché Lambda si connetta al cluster, memorizza le credenziali di autenticazione (nome utente e password) in un segreto di Secrets Manager e fai riferimento a questo segreto durante la configurazione della mappatura dell'origine degli eventi.
Per ulteriori informazioni sull'uso di Secrets Manager, consulta Autenticazione delle credenziali di accesso con Secrets Manager nella Amazon Managed Streaming for Apache Kafka Developer Guide.
Nota
Amazon MSK non supporta SASL/PLAIN l'autenticazione.
Autenticazione TLS reciproca
Mutual TLS (mTLS) fornisce l'autenticazione bidirezionale tra il client e il server. Il client invia un certificato al server affinché il server verifichi il client. Il server invia inoltre un certificato al client per consentire al client di verificare il server.
Per le integrazioni Amazon MSK con Lambda, il cluster MSK funge da server e Lambda funge da client.
-
Affinché Lambda verifichi il tuo cluster MSK, configuri un certificato client come segreto in Secrets Manager e fai riferimento a questo certificato nella configurazione di mappatura delle sorgenti degli eventi. Il certificato client deve essere firmato da un'autorità di certificazione (CA) nel trust store del server.
-
Il cluster MSK invia anche un certificato server a Lambda. Il certificato del server deve essere firmato da un'autorità di certificazione (CA) nel AWS trust store.
Amazon MSK non supporta certificati server autofirmati. Tutti i broker di Amazon MSK utilizzano certificati pubblici firmati da Amazon Trust Services CAs
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.
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-----
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-----" }
Per ulteriori informazioni su MTL per Amazon MSK e istruzioni su come generare un certificato client, consulta l'autenticazione client Mutual TLS per Amazon MSK nella Amazon Managed Streaming for Apache Kafka Developer Guide.
Autenticazione IAM
Puoi utilizzare AWS Identity and Access Management (IAM) per autenticare l'identità dei client che si connettono al cluster MSK. Con l'autenticazione IAM, Lambda si affida alle autorizzazioni del ruolo di esecuzione della funzione per connettersi al cluster, recuperare i record ed eseguire altre azioni richieste. Per un esempio di policy che contiene le autorizzazioni necessarie, consulta Create authorization policies for the IAM nella Amazon Managed Streaming for Apache Kafka Developer Guide.
Se l'autenticazione IAM è attiva sul tuo cluster MSK e non fornisci un segreto, Lambda utilizza automaticamente l'autenticazione IAM.
Per ulteriori informazioni sull'autenticazione IAM in Amazon MSK, consulta IAM access control.
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:
mTLS (segreto fornito per mTLS)
SASL/SCRAM (secret provided for SASL/SCRAM)
IAM SASL (nessun segreto fornito e autenticazione IAM attiva)
TLS non autenticato (nessun segreto fornito e autenticazione IAM non attiva)
Testo semplice (nessun segreto fornito e autenticazione IAM e TLS non autenticato non attivi)
Nota
Se Lambda non riesce a connettersi al tipo di broker più sicuro, non proverà a connettersi a un tipo di broker diverso (più debole). Se vuoi che Lambda scelga un tipo di broker più debole, disattiva tutti i metodi di autenticazione più forti sul tuo cluster.
