Configurazione dei metodi di autenticazione dei cluster Amazon MSK in Lambda - AWS Lambda
Accesso non autenticatoAutenticazione SASL/SCRAMAutenticazione TLS reciprocaAutenticazione IAMCome Lambda sceglie un broker bootstrap

Configurazione dei metodi di autenticazione dei cluster Amazon MSK in Lambda

Lambda ha bisogno dell'autorizzazione per accedere al cluster Amazon MSK, recuperare registri ed eseguire altri processi. Amazon MSK supporta diversi metodi per l'autenticazione con il cluster MSK.

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 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 di Secrets Manager e fare riferimento a questo segreto durante la configurazione della mappatura dell'origine eventi.

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

Nota

Amazon MSK non supporta l'autenticazione SASL/PLAIN.

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. Il server invia inoltre un certificato al client affinché il client verifichi 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) presente nel trust store del server.

  • Il cluster MSK invia anche un certificato server a Lambda. Il certificato server deve essere firmato da un'autorità di certificazione (CA) presente nel trust store AWS.

Amazon MSK non supporta i certificati server autofirmati. 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.

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 il PBES1 (ma non PBES2) come algoritmi di crittografia a chiave privata.

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

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

Autenticazione IAM

È possibile utilizzare IAM per autenticare l'identità dei client che si connettono al cluster MSK. Con l'autenticazione IAM, Lambda si basa sulle autorizzazioni nel ruolo di esecuzione della funzione per connettersi al cluster, recuperare i record ed eseguire altre azioni necessarie. 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 per l'autenticazione, 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 (segreto fornito per 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.