Questa pagina descrive i metodi di autenticazione supportati per le applicazioni client che si connettono ai broker di Google Cloud Managed Service per Apache Kafka.
Per le applicazioni client Google Cloud Managed Service per Apache Kafka in esecuzione su servizi Google Cloud come Google Kubernetes Engine, Compute Engine, Cloud Run o Cloud Run Functions, hai a disposizione le seguenti opzioni di autenticazione:
SASL/OAUTHBEARER (consigliato): questo è il metodo più semplice e sicuro per i client all'interno di Google Cloud. Utilizza le credenziali predefinite dell'applicazione (ADC) per trovare automaticamente l'identità del account di servizio associata all'ambiente. In questo modo non è più necessario gestire e distribuire file di credenziali statiche come le chiavi del account di servizio.
SASL/PLAIN: questo è un metodo utile per lo sviluppo iniziale. Il client esegue l'autenticazione utilizzando una chiave account di servizio di lunga durata.
mTLS: questa è un'opzione se lo standard della tua organizzazione è l'autenticazione basata su certificati. La tua applicazione su Google Cloud è configurata con un certificato e una chiave client.
Per le applicazioni client in esecuzione al di fuori di Google Cloud, ad esempio in un data center on-premise o su un altro provider cloud, prendi in considerazione i seguenti metodi di autenticazione. Scegli il metodo migliore in base alla postura di sicurezza e all'infrastruttura di identità esistente della tua organizzazione.
Federazione delle identità dei workload con SASL/OAUTHBEARER (consigliato): questo è il metodo più sicuro per i client esterni. Consente di concedere alle identità di sistemi esterni, come AWS, Microsoft Azure o un provider di identità on-premise come ADFS, la possibilità di rappresentare un service accountGoogle Cloud . Anziché gestire le chiavi dell'account di servizio a lunga durata, il client utilizza le proprie credenziali preferite per ottenere un token di accesso Google Cloud a breve durata. Il client utilizza quindi questo token per l'autenticazione, il che riduce significativamente il rischio per la sicurezza associato ai file di credenziali statiche.
mTLS: questo metodo è indipendente dal provider ed è adatto se la tua organizzazione utilizza già un'infrastruttura a chiave pubblica (PKI) per gestire i certificati TLS per l'identità del servizio. Consente ai client di autenticarsi senza un'identità specifica di Google Cloud. Tuttavia, in modo simile all'utilizzo delle chiavi dell'account di servizio, questo approccio richiede di gestire il ciclo di vita e la distribuzione di credenziali di lunga durata, come i certificati client.
SASL/PLAIN con una account di servizio account: questo metodo fornisce un modo diretto per un client esterno di autenticarsi come identità Google Cloud . Scarica un file JSON della chiave dell'account di servizio e lo utilizzi nella configurazione SASL/PLAIN del client. Questo metodo è generalmente sconsigliato per i carichi di lavoro di produzione perché richiede la gestione e la protezione di una credenziale statica di lunga durata lato client.
Confronto delle funzionalità tra SASL e mTLS
Il meccanismo di autenticazione principale per Managed Service per Apache Kafka è SASL (Simple Authentication and Security Layer), che si integra direttamente con i servizi di identità diGoogle Cloud. Come base, SASL autentica i client utilizzando un'entità IAM Google Cloud , ad esempio un service account. Per l'autorizzazione, SASL offre flessibilità: puoi gestire l'accesso ai cluster utilizzando ruoli IAM granulari ed elenchi di controllo dell'accesso (ACL) di Kafka.
Al contrario, mTLS offre un metodo di autenticazione indipendente dal fornitore che non si basa su Google Cloud IAM. Al contrario, mTLS autentica un client in base al suo certificato TLS, in cui l'identità deriva dal nome soggetto del certificato.
Questa distinzione porta a una differenza fondamentale nel modo in cui viene gestita l'autorizzazione. A differenza delle entità SASL, le entità mTLS devono essere autorizzate esclusivamente utilizzando gli ACL Kafka; non possono essere gestite con i ruoli IAM. Google Cloud
Ti consigliamo vivamente di configurare gli ACL Kafka per il tuo cluster. Se non sono impostate ACL, il comportamento predefinito di Kafka concede a tutti i principal autenticati, che utilizzino SASL o mTLS, l'accesso completo al cluster. Per maggiori informazioni su come configurare gli elenchi ACL Kafka, consulta Creare un elenco ACL Managed Service per Apache Kafka.
Managed Service per Apache Kafka supporta l'autenticazione mTLS con certificati client emessi da autorità di certificazione presenti in CA Service. Se la tua organizzazione utilizza una radice di attendibilità esterna, puoi integrarla creando un'autorità di certificazione subordinata all'interno di CA Service che si collega alla tua autorità di certificazione esterna.
La seguente tabella mette a confronto le funzionalità dei metodi di autenticazione.
| Funzionalità | SASL/OAUTHBEARER | SASL/PLAIN | mTLS |
|---|---|---|---|
| Identità principale | Google Cloud Entità IAM | Google Cloud Entità IAM | Nome del soggetto del certificato |
| Tipo di credenziali | Credenziali predefinite dell'applicazione (ADC) o token OAuth 2.0 | Chiave dell'account di servizio con codifica Base64 | Certificato client e chiave privata |
| Metodo di autorizzazione | Google Cloud Ruoli IAM o ACL Kafka | Google Cloud Ruoli IAM o ACL Kafka | Solo ACL Kafka |
| Caso d'uso | Client su Google Cloud; client esterni che utilizzano la federazione delle identità per i workload | Client semplici, scenari di test o sistemi legacy in cui è necessario utilizzare una chiave del account di servizio. | Indipendente dal fornitore; ideale per applicazioni on-premise, multi-cloud o PKI esistenti. |
| Configurazione client | Configurazione JAAS con classe di gestione dell'accesso specializzata (Java) o un server di autenticazione locale (non Java) | Configurazione JAAS con PlainLoginModule standard (Java) | Proprietà di keystore e truststore (ad esempio security.protocol=SSL) |
| Disponibilità dei cluster | Tutti i cluster | Tutti i cluster | Cluster creati dopo il 24 giugno 2025 |
Scegliere SASL o mTLS
La scelta del metodo di autenticazione è guidata dalle norme di sicurezza e dall'infrastruttura esistente della tua organizzazione. Per la maggior parte dei casi d'uso, consigliamo di utilizzare SASL con Google Cloud IAM.
SASL con Google Cloud IAM o la federazione delle identità per i workload offre l'esperienza più flessibile e integrata per l'autenticazione e l'autorizzazione. Utilizza il sistema di identità di Google Cloud come unica fonte attendibile per la gestione delle autorizzazioni. Scegli questo percorso se vuoi:
Gestisci centralmente le autorizzazioni per i client Kafka utilizzando i ruoli IAMGoogle Cloud che conosci bene.
Evita di gestire le credenziali statiche sui client.
Consenti ai client di altri cloud come AWS, Azure o ai provider di identità on-premise come Okta o ADFS di autenticarsi utilizzando la federazione delle identità dei carichi di lavoro. Questo metodo fornisce una soluzione di identità sicura e indipendente dal cloud senza dover passare a un protocollo di autenticazione diverso.
Scegli mTLS se la tua organizzazione ha un requisito rigoroso per l'autenticazione basata su certificati. Questa necessità si presenta quando esegui la migrazione di un'implementazione Kafka on-premise esistente che utilizza già certificati TLS per l'identità o quando la policy aziendale impone certificati client per tutte le applicazioni. Sebbene mTLS fornisca una solida sicurezza a livello di trasporto, ricorda che l'autorizzazione per i client mTLS deve essere gestita esclusivamente con gli elenchi ACL Kafka, che sono separati da Google Cloud IAM.
Flusso di lavoro per la configurazione di SASL/PLAIN o SASL/OAUTHBEARER
La configurazione di un client per l'utilizzo dell'autenticazione SASL con Managed Service for Apache Kafka comporta la concessione di autorizzazioni all'identità del client e la configurazione dell'applicazione client in base al meccanismo SASL scelto. Di seguito è riportata una panoramica del workflow richiesto. Per istruzioni dettagliate su come configurare SASL, vedi Configurare l'autenticazione SASL.
Concedi autorizzazioni IAM. Devi prima concedere il ruolo Client Kafka gestito (
roles/managedkafka.client) al account di servizio utilizzato dal client per l'autenticazione. Questo ruolo fornisce l'autorizzazionemanagedkafka.clusters.connectnecessaria per connettersi ai cluster Kafka all'interno del progetto.Configura il client Kafka. La configurazione specifica del client dipende dal meccanismo SASL/OAUTHBEARER o SASL/PLAIN che utilizzi.
Per SASL/OAUTHBEARER (consigliato): questo meccanismo utilizza le credenziali predefinite dell'applicazione (ADC). La configurazione dipende dalla lingua del cliente:
Client Java: aggiungi la libreria di autenticazione Google Cloud specializzata al classpath della tua applicazione. Poi, configura le proprietà del client Kafka per utilizzare la classe
GcpLoginCallbackHandlerfornita, che gestisce automaticamente l'autenticazione utilizzando ADC.GcpLoginCallbackHandlerè una classe utilizzata con il meccanismo di autenticazione OAUTHBEARER di Kafka, progettata specificamente per l'utilizzo con Managed Service per Apache Kafka. Gestisce il processo di ottenimento di un token web JSON (JWT) dal provider di identità di Google, consentendo ai client Kafka di autenticarsi con il servizio utilizzando ADC.Client non Java: esegui un server di autenticazione locale fornito sulla macchina del client. Questo server utilizza ADC per recuperare le credenziali e le fornisce al client Kafka. Il client viene quindi configurato per ottenere il token di autenticazione dall'endpoint di questo server locale.
Per SASL/PLAIN
Questo meccanismo utilizza una combinazione di nome utente e password. L'applicazione client deve essere configurata per utilizzare il protocollo di sicurezza SASL_SSL, il meccanismo PLAIN e una configurazione JAAS che specifica la classe
PlainLoginModule.Il nome utente è l'indirizzo email del account di servizio. La password può essere generata in due modi:
Codificando in base64 un file JSON della chiave del account di servizio.
Ottenendo un token di accesso di breve durata.
Configurare l'autorizzazione. Dopo che un client ha eseguito l'autenticazione utilizzando SASL, il suo accesso è controllato dalle autorizzazioni definite nei ruoli IAM o negli ACL Kafka sul cluster.
Limitazioni di SASL
Il metodo di autenticazione SASL presenta le seguenti limitazioni:
L'autenticazione SASL è intrinsecamente legata alle entità IAM. Non è adatto alle organizzazioni che richiedono una separazione rigorosa dall'identitàGoogle Cloud o che utilizzano identità non Google, a meno che non configuri la federazione delle identità per i workload.
SASL non utilizza i certificati client per l'autenticazione. Non è adatto alle organizzazioni che si affidano a una PKI esistente per identificare le applicazioni.
Workflow per la configurazione di mTLS
La configurazione di mTLS per Managed Service per Apache Kafka prevede la configurazione delle autorità di certificazione, del cluster Kafka e dei client Kafka. Per istruzioni dettagliate su come configurare mTLS, vedi Configurare l'autenticazione mTLS.
Configura le autorità di certificazione (CA). Devi prima creare e configurare i pool di CA in Certificate Authority Service (servizio CA). Se crei pool di CA in un progetto diverso, assicurati di concedere all'agente di servizio Managed Service per Apache Kafka (
service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com) l'autorizzazione per accedere a questi pool. Devi creare certificati radice e subordinati all'interno dei pool di CA.Configura il cluster Kafka. Crea o aggiorna il cluster per attivare mTLS fornendo gli identificatori di risorsa dei pool di CA configurati. Ti consigliamo inoltre di configurare la proprietà del broker
ssl.principal.mapping.rulesper creare nomi principali semplificati da utilizzare negli elenchi di controllo degli accessi. Puoi farlo utilizzando i comandi Google Cloud CLI.Configura i client Kafka. Ottieni i certificati client dalle CA e installali nell'ambiente del client, ad esempio in un keystore Java. L'applicazione client deve quindi essere configurata con il protocollo di sicurezza (SSL) corretto e la posizione del keystore per connettersi alla porta di bootstrap mTLS dedicata del cluster, ovvero
9192.Monitora mTLS. Dopo la configurazione, monitora la metrica
managedkafka.googleapis.com/mtls_truststore_update_countper verificare che il cluster aggiorni correttamente i certificati CA dai pool del servizio CA, operazione che tenta di eseguire periodicamente. Puoi anche utilizzare Cloud Logging.
Limitazioni di mTLS
La funzionalità mTLS reciproca presenta le seguenti limitazioni:
Puoi utilizzare la funzionalità mTLS solo sui cluster Managed Service per Apache Kafka creati dopo il 24 giugno 2025.
Devi configurare l'autorizzazione per i principal mTLS utilizzando gli elenchi ACL Kafka. Non puoi utilizzare le associazioni di ruoli IAM per autorizzare i client mTLS.
Il servizio autentica solo i client che presentano certificati gestiti da CA Service. Tuttavia, puoi integrare una radice di attendibilità esterna creando una CA subordinata all'interno di CA Service che si collega alla tua CA esterna.
Puoi configurare un cluster in modo che consideri attendibili un massimo di 10 pool di CA.