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 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
SASL/SCRAM authentication
Lambda supporta l'autenticazione Simple Authentication e 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 supporta il testo in SASL/SCRAM chiaro (). SASL_PLAINTEXT Per ulteriori informazioni sull' SASL/SCRAM autenticazione, consulta RFC 5802.
Lambda supporta SASL/PLAIN anche l'autenticazione. Poiché questo meccanismo utilizza credenziali in chiaro, la connessione al server deve utilizzare la crittografia TLS per garantire che le credenziali siano protette.
Per l'autenticazione SASL, è necessario archiviare le credenziali di accesso come segreto in AWS Secrets Manager. Per ulteriori informazioni sull'utilizzo di Secrets Manager, consulta Create an AWS Secrets Manager secret nella Guida AWS Secrets Manager per l'utente.
Importante
Per utilizzare Secrets Manager per l'autenticazione, i segreti devono essere archiviati nella stessa AWS area della Lambda Event Function.
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.
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 CA/self-signed certificato 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 CA/self-signed certificato privato, si configura il certificato CA principale del server (come segreto in Secrets Manager). Lambda utilizza il certificato root per verificare i broker Kafka.
Per ulteriori informazioni su mTLS, consultare Introduzione dell'autenticazione TLS reciproca per Amazon MSK come origine eventi
Autenticazione OAuth 2.0
Lambda supporta SASL/OAUTHBEARER l'autenticazione con crittografia TLS (). SASL_SSL Lambda richiede un token di accesso al tuo provider di identità OAuth 2.0 e lo presenta ai tuoi broker Kafka. Lambda aggiorna il token prima della scadenza. Configura i tuoi broker per convalidare i token dello stesso provider di identità.
Per utilizzare questo metodo, scegli OAUTHBEARER_AUTH come Type di a SourceAccessConfiguratione fornisci l'ARN del Secrets Manager del tuo segreto OAuth nel campo. URI Per il contenuto del segreto, vedi. Configurazione del segreto OAuth
Lambda supporta due tipi di concessione. I campi archiviati nel segreto determinano quale viene utilizzato da Lambda.
-
Credenziali client: Lambda invia un ID client e un client secret all'endpoint del token. Utilizza questo tipo di concessione quando il tuo provider di identità rilascia un segreto client.
-
Portatore JWT: Lambda firma un'asserzione JSON Web Token (JWT) con una chiave privata e invia l'asserzione all'endpoint del token. Usa questo tipo di concessione quando il tuo provider di identità si aspetta un'asserzione firmata anziché un segreto del cliente.
Se il tuo provider di identità o i tuoi broker richiedono valori aggiuntivi, fornisci ciascuno di essi come voce di configurazione dell'accesso all'origine. Inserisci il valore letterale nel URI campo anziché un ARN segreto.
-
OAUTHBEARER_SCOPE— L'ambito richiesto da Lambda quando richiede un token. -
OAUTHBEARER_AUDIENCE— Il pubblico richiesto da Lambda quando richiede un token. -
OAUTHBEARER_LOGICAL_CLUSTER— L'ID logico del cluster che Lambda invia ai tuoi broker come estensione SASL. -
OAUTHBEARER_IDENTITY_POOL— L'ID del pool di identità che Lambda invia ai tuoi broker come estensione SASL.
Nota
Questi quattro tipi richiedono un tipo di autenticazione OAuth 2.0. Forniscili OAUTHBEARER_AUTH o fornisci soloOAUTHBEARER_AUDIENCE. IAM_OAUTHBEARER_AUTH Se ne fornisci uno senza uno di questi tipi di autenticazione, Lambda restituisce un errore di convalida.
Se i tuoi broker presentano un certificato firmato da una CA privata, assicurati anche che Lambda possa verificarlo. SERVER_ROOT_CA_CERTIFICATE Per ulteriori informazioni, consulta Configurazione del segreto del certificato CA root del server.
Autenticazione IAM
Se il tuo cluster è un cluster Amazon MSK raggiungibile tramite la tua configurazione di rete, puoi registrarlo come origine di eventi Kafka autogestita e autenticarti con IAM. Le configurazioni di rete personalizzate includono un nome di dominio personalizzato davanti ai broker o una connessione da un altro account. Lambda firma ogni connessione con le credenziali del ruolo di esecuzione della funzione, in modo da non archiviare alcuna credenziale in Secrets Manager.
Per utilizzare questo metodo, attiva il controllo degli accessi IAM sul tuo cluster. Quindi scegli IAM_AUTH come configurazione Type di accesso alla sorgente e ometti il URI campo. Il ruolo di esecuzione della funzione richiede le autorizzazioni del cluster descritte in. Configurazione delle autorizzazioni del ruolo di esecuzione Lambda
Se i tuoi broker presentano un certificato firmato da una CA privata, assicurati anche che Lambda possa verificarlo. SERVER_ROOT_CA_CERTIFICATE Un nome di dominio personalizzato di fronte ai tuoi broker di solito ne ha bisogno.
Autenticazione IAM con SASL/OAUTHBEARER
Se i tuoi broker accettano i token OAuth 2.0, puoi utilizzarli AWS come provider di identità. Lambda presenta un token di identità AWS web ai tuoi broker. SASL/OAUTHBEARER Lambda richiede un token di breve durata per il ruolo di esecuzione della funzione con l'sts:GetWebIdentityTokenazione, quindi non memorizzi alcuna credenziale in Secrets Manager. Lambda richiede un nuovo token prima della scadenza di quello corrente.
Per utilizzare questo metodo, scegli IAM_OAUTHBEARER_AUTH come configurazione Type di accesso al codice sorgente e ometti il campo. URI Devi anche fornire il pubblico che OAUTHBEARER_AUDIENCE i tuoi broker si aspettano. Il ruolo di esecuzione della funzione richiede l'autorizzazione per la chiamatasts:GetWebIdentityToken.
Configura i tuoi broker in modo che si AWS fidino di un provider di identità OpenID Connect (OIDC) prima di creare la mappatura delle sorgenti degli eventi. Se i tuoi broker non si fidano dell' AWS emittente, rifiutano il token e Lambda non può leggere i tuoi argomenti.
Nota
IAM_OAUTHBEARER_AUTHsupporta solo. OAUTHBEARER_AUDIENCE Se fornisci anche, o OAUTHBEARER_SCOPE OAUTHBEARER_LOGICAL_CLUSTEROAUTHBEARER_IDENTITY_POOL, Lambda restituisce un errore di convalida.
Configurazione del segreto del certificato client
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
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, 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 crittografia TLS con certificati firmati da una CA privata. Puoi utilizzare la crittografia TLS per l'autenticazione VPC SASL/SCRAM o MTLS. SASL/PLAIN
Il segreto del certificato CA root del server richiede un campo che contiene il certificato CA root del broker Kafka in formato PEM. Il seguente esempio illustra la struttura del segreto.
{"certificate":"-----BEGIN CERTIFICATE-----
MIID7zCCAtegAwIBAgIBADANBgkqhkiG9w0BAQsFADCBmDELMAkGA1UEBhMCVVMx
EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAjBgNVBAoT
HFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xOzA5BgNVBAMTMlN0YXJmaWVs
ZCBTZXJ2aWNlcyBSb290IENlcnRpZmljYXRlIEF1dG...
-----END CERTIFICATE-----"
}
Configurazione del segreto OAuth
Questo segreto viene creato quando lo si utilizza. OAUTHBEARER_AUTH Il segreto è un documento JSON. Ogni segreto OAuth richiede e. oauthTokenEndpointUrl oauthClientId Aggiungi i campi per un solo tipo di concessione. Se fornisci campi di entrambi i tipi di concessione, Lambda restituisce un errore di convalida.
| Campo | Richiesto | Description |
|---|---|---|
|
Y |
L'endpoint token del tuo provider di identità. Deve essere un URL HTTPS. |
|
Y |
L'ID cliente emesso dal tuo provider di identità. |
|
Solo le credenziali del cliente |
Il segreto del cliente rilasciato dal tuo provider di identità. |
|
Solo portatore JWT |
L'identità dell'account di servizio che Lambda inserisce nell'asserzione JWT. |
|
Solo portatore JWT |
La chiave privata utilizzata da Lambda per firmare l'asserzione JWT, in formato PEM. |
|
N |
La durata dell'affermazione JWT firmata da Lambda. Si applica solo al tipo di sovvenzione JWT bearer. |
|
N |
Il certificato CA principale del tuo provider di identità, in formato PEM. Forniscilo se il tuo provider di identità presenta un certificato firmato da una CA privata. |
L'esempio seguente mostra un segreto per il tipo di concessione delle credenziali del client.
{"oauthTokenEndpointUrl":"https://idp.example.com/oauth2/token",
"oauthClientId":"my-client-id",
"oauthClientSecret":"my-client-secret"}
L'esempio seguente mostra un segreto per il tipo di concessione JWT bearer.
{"oauthTokenEndpointUrl":"https://idp.example.com/oauth2/token",
"oauthClientId":"my-client-id",
"oauthClientEmail":"my-service-account@example.com",
"oauthPrivateKey":"-----BEGIN PRIVATE KEY-----
<private key contents>
-----END PRIVATE KEY-----"}
Importante
Memorizza il segreto nella stessa AWS regione della funzione Lambda. Lambda legge il segreto con il ruolo di esecuzione della funzione, quindi quel ruolo necessita dell'secretsmanager:GetSecretValueautorizzazione per il segreto.
Puoi ruotare le credenziali nel segreto senza ricreare la mappatura della fonte dell'evento. Lambda rileva i nuovi valori e richiede un nuovo token.
