Controllo dell'accesso con gli ACL Kafka

Questo documento descrive come utilizzare gli elenchi di controllo dell'accesso (ACL) di Apache Kafka per il controllo dell'accesso in Google Cloud Managed Service per Apache Kafka.

Gli ACL di Apache Kafka forniscono un controllo dell'accesso granulare all'interno del cluster Kafka. Managed Service per Apache Kafka abilita StandardAuthorizer predefinito, che archivia gli ACL nei metadati del cluster Kafka basati su KRaft.

  • Questi ACL controllano quali utenti autenticati possono eseguire operazioni specifiche su risorse Kafka specifiche, ad esempio produrre o consumare messaggi in un argomento.

  • Questi ACL sono utili per controllare le interazioni con il cluster utilizzando i client Apache Kafka standard, che sono soggetti solo a un controllo IAM a livello di cluster per la connessione iniziale. Per ulteriori informazioni, consulta Controllo dell'accesso con IAM.

Come funziona il controllo dell'accesso agli ACL di Kafka

Il client interagisce con l'autorizzatore ACL standard di Kafka all'interno del cluster. L'autorizzatore valuta gli ACL Apache Kafka pertinenti per autorizzare operazioni specifiche richieste dall'entità, ad esempio la produzione in un argomento o il consumo da un gruppo. L'entità utilizzata per il controllo ACL viene derivata da uno dei seguenti metodi di autenticazione:

  • SASL: l'entità IAM, ad esempio l'indirizzo email di un account di servizio.

  • mTLS: il nome distinto (DN) del certificato client, potenzialmente trasformato dalle regole di mappatura delle entità.

Per una sicurezza completa, devi configurare quanto segue:

  • Autorizzazioni IAM per l'accesso di gestione. Per ulteriori informazioni, consulta Controllo dell'accesso con IAM.

  • ACL Kafka per l'accesso ai dati e le operazioni in-cluster da client Apache Kafka open source, indipendentemente dal metodo di autenticazione.

Utilizzo degli ACL di Apache Kafka

Le associazioni ACL di Apache Kafka hanno il seguente formato:


Principal P is [Allowed/Denied] Operation O From Host H on any resource matching Resource Pattern RP.

Di seguito è riportato un elenco di informazioni importanti sul formato:

  • Entità(P): l'identità utente autorizzata. È preceduta da User:.

    • Per l'autenticazione SASL, si tratta dell'entità IAM, ad esempio User:my-service-account@my-project.iam.gserviceaccount.com.

    • Per l'autenticazione mTLS, si tratta del nome distinto (DN) del certificato client, ad esempio User:CN=my-client,OU=my-org-unit. Il formato esatto dipende dal soggetto del certificato. Le regole di mappatura delle entità possono trasformare questo valore.

  • Tipo di autorizzazione(Consentita/Negata): se l'associazione ACL consente o nega l'accesso. Le associazioni di negazione hanno la precedenza.

  • Operazione(O): l'azione eseguita, ad esempio Lettura, Scrittura o Creazione. Per informazioni sulle operazioni che si applicano alle risorse per vari protocolli Kafka, consulta Operations and Resources on Protocols nella documentazione di Apache Kafka.

  • Host(H): la macchina da cui ha origine la richiesta. Poiché Managed Service per Apache Kafka traduce gli indirizzi di rete dei client, l'utilizzo di host diversi da '*' non è supportato.

  • Pattern di risorsa(RP): un pattern utilizzato per trovare risorse specifiche. Un pattern di risorsa è costituito da un tipo di risorsa, un nome risorsa e un tipo di pattern (LITERAL o PREFIXED).

Accesso predefinito

I cluster Managed Service per Apache Kafka operano con la proprietà Apache Kafka allow.everyone.if.no.acl.found impostata su true. La presenza o l'assenza di ACL Kafka determina direttamente il livello di accesso alle risorse:

  • Se non sono definiti ACL Kafka per una risorsa specifica, ad esempio un argomento, a tutte le entità autenticate viene concesso l'accesso. Questa configurazione consente ai cluster Managed Service per Apache Kafka di essere immediatamente operativi, senza la necessità di configurare gli ACL.

  • Non appena definisci un ACL Kafka per la risorsa, l'accesso diventa limitato. Solo le entità a cui è stata concessa esplicitamente l'autorizzazione utilizzando una voce ALLOW in un ACL Kafka possono accedere alle risorse corrispondenti (a meno che non siano bloccate specificamente da una voce DENY).

Managed Service per Apache Kafka concede al suo service agent l'accesso amministrativo al cluster. Questo accesso consente al service agent di eseguire le operazioni richieste dall'API Managed Service per Apache Kafka, indipendentemente dagli altri ACL configurati nel cluster. Managed Service per Apache Kafka esegue questa operazione modificando l'implementazione di StandardAuthorizer. La modifica concede al service agent autorizzazioni simili a quelle dei superuser, ad eccezione delle operazioni di lettura e scrittura. Non puoi modificare questa configurazione.

Entità Kafka

Le entità Kafka per i cluster Managed Service per Apache Kafka vengono specificate con il prefisso dell'autorizzatore standard di Kafka "User:".

  • Per SASL/IAM: l'entità è l' Google Cloud account. Ad esempio, per concedere l'accesso al account di servizio test-kafka-client@test-project.iam.gserviceaccount.com, utilizza l'entità Kafka "User:test-kafka-client@test-project.iam.gserviceaccount.com". Le entità ACL Kafka devono specificare un utente, un account di servizio o una singola entità IAM, ma non un gruppo o un insieme di entità. Gli ACL Kafka non supportano la risoluzione delle appartenenze ai gruppi per le Google Cloud entità.

  • Per mTLS: l'entità viene derivata dal nome distinto (DN) del soggetto del certificato client. Ad esempio, User:CN=client1,OU=dev,O=MyOrg,L=City,ST=State,C=US. Puoi utilizzare le regole di mappatura delle entità mTLS principal mapping rules per trasformare il DN in una stringa di entità più intuitiva per gli ACL.

Per creare un ACL che si applichi a tutti i membri di un gruppo Google o di un insieme di entità, puoi utilizzare un'entità account di servizio proxy e la simulazione dell'identità del account di servizio:

  1. Crea un service account da utilizzare come proxy per il gruppo.

  2. Concedi al gruppo Google o all'insieme di entità il ruolo Creatore token account di servizio nel service account. Consulta Gestire l'accesso ai service account

  3. Aggiungi gli ACL Kafka per il account di servizio proxy. Un'entità di esempio potrebbe essere: User:group-proxy@test-project.iam.gserviceaccount.com.

  4. Utilizza la simulazione dell'identità del service account nei client Kafka per eseguire l'autenticazione a Kafka come account di servizio. Google Cloud IAM autorizza una singola entità come membro del gruppo autorizzato a simulare l'identità del service account proxy. Kafka autorizza il account di servizio proxy in base agli ACL esistenti nel cluster.

Operazioni Kafka per produttori e consumatori

Un'operazione è un'azione eseguita su una risorsa. Per ogni risorsa, un'operazione viene mappata a una o più richieste di protocollo Kafka per quella risorsa. Ad esempio, un'operazione READ per il tipo di risorsa topic viene mappata ai Fetch, OffsetCommit e TxnOffsetCommit protocolli Apache Kafka.

Per concedere a un produttore principale l'accesso a un argomento, segui questi passaggi:

  1. Nella risorsa dell'argomento, consenti le operazioni WRITE e CREATE.

  2. Se utilizzi gli ID transazionali, nella risorsa ID transazionale, consenti l'operazione WRITE.

Per concedere a un consumatore principale l'accesso a un argomento, segui questi passaggi:

  1. Nella risorsa dell'argomento, consenti l'operazione READ.

  2. Nella risorsa del gruppo di consumer, consenti l'operazione READ.

Per ulteriori informazioni sulle operazioni valide sulle risorse supportate dall'API Kafka, consulta Operations and Resources on Protocols nella documentazione di Apache Kafka.

Configurare gli ACL per il comportamento di negazione predefinita

I cluster Kafka gestiti sono configurati con allow.everyone.if.no.acl.found = true. Pertanto, per impostazione predefinita, se non sono impostati ACL su una risorsa, tutte le entità possono accedere alla risorsa.

Per configurare un comportamento di default-deny simile a quello di IAM, puoi prima configurare l'accesso per un utente amministratore a tutte le risorse del cluster. Di conseguenza, ogni risorsa riceve un ACL definito e il comportamento allow.everyone.if.no.acl.found viene eliminato. Per impostazione predefinita, a qualsiasi entità non consentita esplicitamente da un ACL ALLOW viene negato l'accesso.

Ad esempio, per impostare gli ACL su tutte le risorse del cluster per il account di servizio clusterAdmin@test-project.iam.gserviceaccount.com, crea le seguenti voci ACL.

Il seguente comando gcloud CLI concede a un account di servizio denominato clusterAdmin@test-project.iam.gserviceaccount.com l'accesso amministrativo completo (--operation=ALL) a un cluster Kafka specifico che si trova in una regione specifica. Questa autorizzazione consente al account di servizio di eseguire qualsiasi operazione sul cluster da qualsiasi host.

gcloud managed-kafka acls add-acl-entry cluster \
    --principal=`User:clusterAdmin@test-project.iam.gserviceaccount.com` \
    --operation=ALL \
    --permission-type=ALLOW \
    --host=* \
    --cluster=CLUSTER_ID \
    --location=LOCATION

Il seguente comando gcloud CLI concede a un account di servizio denominato clusterAdmin@test-project.iam.gserviceaccount.com l'accesso amministrativo completo (--operation=ALL) a tutti gli argomenti all'interno di un cluster Kafka specifico che si trova in una regione specifica. Questa autorizzazione consente al service account di eseguire qualsiasi operazione su tutti gli argomenti da qualsiasi host.

gcloud managed-kafka acls add-acl-entry allTopics \
    --principal=`User:clusterAdmin@test-project.iam.gserviceaccount.com` \
    --operation=ALL \
    --permission-type=ALLOW \
    --host=* \
    --cluster=CLUSTER_ID \
    --location=LOCATION

Il seguente comando gcloud CLI concede a un account di servizio denominato clusterAdmin@test-project.iam.gserviceaccount.com l'accesso amministrativo completo (--operation=ALL) a tutti i gruppi di consumer all'interno di un cluster Kafka specifico che si trova in una regione specifica. Questa autorizzazione consente al account di servizio di eseguire qualsiasi operazione su tutti i gruppi di consumer da qualsiasi host.

gcloud managed-kafka acls add-acl-entry allConsumerGroups \
    --principal=`User:clusterAdmin@test-project.iam.gserviceaccount.com` \
    --operation=ALL \
    --permission-type=ALLOW \
    --host=* \
    --cluster=CLUSTER_ID \
    --location=LOCATION

Il seguente comando gcloud CLI concede a un account di servizio denominato clusterAdmin@test-project.iam.gserviceaccount.com l'accesso amministrativo completo (--operation=ALL) a tutti gli ID transazionali all'interno di un cluster Kafka specifico che si trova in una regione specifica. Questa autorizzazione consente al account di servizio di eseguire qualsiasi operazione su tutti gli ID transazionali da qualsiasi host.

gcloud managed-kafka acls add-acl-entry allTransactionalIds \
    --principal=`User:clusterAdmin@test-project.iam.gserviceaccount.com` \
    --operation=ALL \
    --permission-type=ALLOW \
    --host=* \
    --cluster=CLUSTER_ID \
    --location=LOCATION

Di seguito è riportato un elenco di informazioni importanti sui comandi:

  • --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com': l'entità a cui si applica l'ACL. L'entità è un Google Cloud account, con il prefisso dell'autorizzatore standard di Kafka User:.

  • --operation=all: l'operazione Kafka concessa, che in questo caso è l'accesso completo.

  • --permission-type=ALLOW: questa voce ACL concede l'accesso.

  • --host='*': l'host da cui l'entità può accedere alla risorsa. '*' concede l'accesso da qualsiasi host. Managed Service per Apache Kafka supporta solo gli ACL con host '*'.

  • CLUSTER_ID: il nome del cluster Managed Service per Apache Kafka.

  • LOCATION: la Google Cloud regione in cui si trova il cluster Managed Service per Apache Kafka, ad esempio us-central1.

Configurare gli ACL

Puoi configurare gli ACL di Apache Kafka con le API ACL di Managed Service per Apache Kafka o con strumenti Apache Kafka open source come l'interfaccia a riga di comando dell'autorizzatore Apache Kafka kafka-acls.sh, o Admin Client.

Managed Service per Apache Kafka organizza gli ACL in base ai pattern di risorse Kafka. Il pattern di risorsa è definito da:

  • Tipo di risorsa: cluster, argomento, gruppo di consumer o ID transazionale

  • Tipo di pattern: letterale o con prefisso (tutte le risorse il cui nome inizia con la stringa fornita)

  • Nome risorsa: il nome o il prefisso della risorsa a cui si applicano le voci ACL.

Una risorsa ACL di Managed Service per Apache Kafka rappresenta tutto il controllo dell'accesso configurato per un singolo pattern di risorse Kafka, come un elenco ripetuto di voci ACL. Il nome della risorsa ACL identifica in modo univoco il pattern di risorse dell'associazione ACL. Per ulteriori informazioni, consulta ID ACL.

Puoi gestire gli ACL di Managed Service per Apache Kafka a livello di risorsa ACL (tutte le voci ACL per un pattern di risorse) o in modo incrementale aggiungendo e rimuovendo singole voci ACL per un pattern di risorse ACL.

Per ulteriori informazioni, consulta Creare un ACL Kafka gestito e Aggiungere una voce ACL Kafka gestita.

Consentire la lettura da un argomento

Per consentire ai client Apache Kafka open source in esecuzione come account di servizio test-kafka-client@test-project.iam.gserviceaccount.com di leggere dall'argomento topic-name, crea una voce ACL di Managed Service per Apache Kafka utilizzando il managed-kafka acls add-acl-entry comando:

gcloud managed-kafka acls add-acl-entry topic/topic-name \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=READ \
    --permission-type=ALLOW \
    --host='*'

Di seguito è riportato un elenco di informazioni importanti sul comando:

  • topic/topic-name: specifica l'argomento Managed Service per Apache Kafka a cui vuoi concedere l'accesso. Sostituisci topic-name con il nome effettivo dell'argomento. Il prefisso topic/ indica che questa voce ACL si applica a un pattern di risorse dell'argomento specifico (letterale).

  • LOCATION: la Google Cloud regione in cui si trova il cluster Managed Service per Apache Kafka, ad esempio us-central1.

  • CLUSTER_ID: il nome del cluster Managed Service per Apache Kafka.

  • --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com': l'entità a cui si applica l'ACL. L'entità è un Google Cloud account, con il prefisso dell'autorizzatore standard di Kafka User:.

  • --operation=READ: l'operazione Kafka concessa, che in questo caso è READ.

  • --permission-type=ALLOW: indica che questa voce ACL concede l'accesso.

  • --host='*': specifica l'host da cui l'entità può accedere alla risorsa. '*' concede l'accesso da qualsiasi host. Managed Service per Apache Kafka supporta solo gli ACL con host '*'.

Per rimuovere l'accesso in lettura, puoi utilizzare il remove-acl-entry comando con gli stessi parametri.

gcloud managed-kafka acls remove-acl-entry topic/topic-name \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=READ \
    --permission-type=ALLOW \
    --host='*'

Consentire la scrittura in tutti gli argomenti con un prefisso comune

Per consentire ai client Apache Kafka open source in esecuzione come account di servizio test-kafka-client@test-project.iam.gserviceaccount.com di scrivere in tutti gli argomenti il cui nome inizia con il prefisso topic-prefix, aggiungi una voce ACL Kafka gestita come segue:

gcloud managed-kafka acls add-acl-entry topicPrefixed/topic-prefix \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=WRITE \
    --permission-type=ALLOW \
    --host='*'

Di seguito è riportato un elenco di informazioni importanti sul comando:

  • topicPrefixed/topic-prefix: specifica il pattern di risorse Managed Service per Apache Kafka a cui vuoi concedere l'accesso. Sostituisci topic-prefix con il prefisso effettivo degli argomenti. Il prefisso topicPrefixed/ indica che questa voce ACL si applica a un pattern di risorse con prefisso: tutti gli argomenti che corrispondono al prefisso specificato.

  • PROJECT: l'ID del tuo Google Cloud progetto in cui si trova il tuo cluster Managed Service per Apache Kafka.

  • LOCATION: la Google Cloud regione in cui si trova il cluster Managed Service per Apache Kafka, ad esempio us-central1.

  • CLUSTER_ID: il nome del cluster Managed Service per Apache Kafka.

  • --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com': l'entità a cui si applica l'ACL. L'entità è un Google Cloud account, con il prefisso dell'autorizzatore standard di Kafka User:.

  • --operation=WRITE: l'operazione Kafka concessa, che in questo caso è WRITE.

  • --permission-type=ALLOW: questa voce ACL concede l'accesso.

  • --host='*': l'host da cui l'entità può accedere alla risorsa. '*' concede l'accesso da qualsiasi host. Managed Service per Apache Kafka supporta solo gli ACL con host '*'.

Per rimuovere l'accesso in scrittura per questo account di servizio, rimuovi la voce ACL:

gcloud managed-kafka acls remove-acl-entry topicPrefixed/topic-prefix \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=WRITE \
    --permission-type=ALLOW \
    --host='*'

Negare la modifica di tutti gli argomenti

Per impedire ai client Apache Kafka open source in esecuzione come account di servizio test-kafka-client@test-project.iam.gserviceaccount.com di modificare tutti gli argomenti in un cluster, puoi creare una risorsa ACL di Managed Service per Apache Kafka con un elenco di AclEntry risorse per negare le operazioni ALTER, ALTER_CONFIGS e DELETE su tutti gli argomenti. Questo approccio definisce lo stato richiesto in una singola configurazione.

In alternativa, puoi ottenere lo stesso risultato aggiungendo in modo imperativo tre voci ACL separate utilizzando il comando gcloud managed-kafka acls add-acl-entry. Questo metodo prevede l'esecuzione del comando per negare l'accesso a ciascuna delle operazioni ALTER, ALTER_CONFIGS, e DELETE, come segue:

gcloud managed-kafka acls add-acl-entry allTopics \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=ALTER \
    --permission-type=DENY \
    --host='*'
gcloud managed-kafka acls add-acl-entry allTopics \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=ALTER_CONFIGS \
    --permission-type=DENY \
    --host='*'
gcloud managed-kafka acls add-acl-entry allTopics \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=DELETE \
    --permission-type=DENY \
    --host='*'

Le seguenti informazioni si applicano a ciascuno dei comandi add-acl-entry:

  • allTopics: specifica che questo ACL si applica a tutti gli argomenti all'interno del cluster Managed Service per Apache Kafka.

  • LOCATION: la Google Cloud regione in cui si trova il cluster Managed Service per Apache Kafka, ad esempio us-central1.

  • CLUSTER_ID: il nome del cluster Managed Service per Apache Kafka.

  • --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com': specifica l'entità a cui si applica l' ACL. L'entità è un Google Cloud account, con il StandardAuthorizer prefisso User:.

  • --operation: specifica l'operazione Kafka negata:

    • ALTER: include azioni come la modifica del numero di partizioni o del fattore di replica.

    • ALTER_CONFIGS: include la modifica delle configurazioni a livello di argomento.

    • DELETE: include l'eliminazione degli argomenti.

  • --permission-type=DENY: indica che queste voci ACL bloccano l'accesso per le operazioni specificate.

  • --host='*': specifica che questa negazione si applica indipendentemente dall'host da cui ha origine la richiesta. Managed Service per Apache Kafka supporta solo gli ACL con host '*'.

Per rimuovere queste limitazioni, utilizza il comando remove-acl-entry per ogni voce aggiunta, utilizzando gli stessi parametri. Ad esempio, per consentire nuovamente l'eliminazione degli argomenti:

gcloud managed-kafka acls remove-acl-entry allTopics \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=DELETE \
    --permission-type=DENY \
    --host='*'

Risoluzione dei problemi relativi agli ACL

L'autorizzatore standard di Apache Kafka scrive i log di audit per impostazione predefinita sulle negazioni di autorizzazione. Se ricevi un errore di autorizzazione Kafka, puoi confermare l'entità, la risorsa e l'operazione a cui è stato negato l'accesso cercando StandardAuthorizerData logAuditMessage nei log del cluster.

Di seguito è riportato un esempio di log del cluster.

org.apache.kafka.metadata.authorizer.StandardAuthorizerData logAuditMessage\n
INFO: Principal = User:556291496362-compute@developer.iam.gserviceaccount.com is
Denied operation = DESCRIBE from host = 172.16.0.20 on resource = Topic:LITERAL:t1
for request = Metadata with resourceRefCount = 1 based on rule DefaultDeny

Passaggi successivi

Apache Kafka® è un marchio registrato di The Apache Software Foundation o delle sue affiliate negli Stati Uniti e/o in altri paesi.