Controllo dell'accesso con gli ACL Kafka

Questo documento descrive come utilizzare le liste di controllo dell'accesso (ACL) di Apache Kafka percontrollo dell'accesso'accesso in Google Cloud Managed Service per Apache Kafka.

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

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

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

Come funziona controllo dell'accesso ACL Kafka

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

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

• TLS reciproco:il nome distinto (DN) del certificato client, potenzialmente trasformato dalle regole di mappatura dei principal.

Per una sicurezza completa, devi configurare quanto segue:

• Autorizzazioni IAM per l'accesso di gestione. Per saperne di più, consulta Controllo dell'accesso con IAM.

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

Utilizzo degli elenchi di controllo dell'accesso Apache Kafka

I binding 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 da autorizzare. Questo valore è preceduto da User:.

  • Per l'autenticazione SASL, si tratta dell'entità IAM, ad esempio User:[e-mail].

  • Per l'autenticazione mTLS, questo è il 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 dei principal possono trasformare questo valore.

• Tipo di autorizzazione(consentita/negata): indica se l'associazione ACL consente o nega l'accesso. I binding di negazione hanno la precedenza.

• Operazione(O): l'azione eseguita, ad esempio lettura, scrittura o creazione. Per informazioni su quali operazioni si applicano a quali risorse per vari protocolli Kafka, consulta Operazioni e risorse sui protocolli 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 client, l'utilizzo di host diversi da '*' non è supportato.

• Pattern risorsa(RP): un pattern utilizzato per trovare corrispondenze con risorse specifiche. Un pattern di risorse è 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 funzionano 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 definite ACL Kafka per una risorsa specifica come un argomento, a tutti i principal autenticati viene concesso l'accesso. Questa configurazione consente ai cluster Managed Service per Apache Kafka di essere immediatamente operativi, senza la necessità di configurare gli elenchi di controllo degli accessi.

• Non appena definisci un ACL Kafka per la risorsa, l'accesso viene limitato. Solo i principal 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 bloccati specificamente da una voce DENY).

Managed Service per Apache Kafka concede al suo service agent l'accesso amministrativo al tuo cluster. Questo accesso consente all'agente di servizio di eseguire le operazioni richieste dall'API Managed Service per Apache Kafka, indipendentemente dalle altre ACL configurate nel cluster. Managed Service per Apache Kafka lo fa modificando l'implementazione di StandardAuthorizer. La modifica concede all'agente di servizio autorizzazioni simili a quelle dei superuser, ad eccezione delle operazioni di lettura e scrittura. Non puoi modificare questa configurazione.

Entità Kafka

I principal Kafka per i cluster Managed Service per Apache Kafka sono specificati con il prefisso Kafka StandardAuthorizer "User:".

• Per SASL/IAM: l'entità è l'account Google Cloud . Ad esempio, per concedere l'accesso al account di servizio [e-mail], utilizza l'entità Kafka "User:[e-mail]". Le entità ACL Kafka devono specificare un utente, un account di servizio o un'entità IAM individuale, ma non un gruppo o un insieme di entità. Le ACL Kafka non supportano la risoluzione delle iscrizioni ai gruppi per i principal Google Cloud .

• Per mTLS reciproco:il principal viene derivato 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 per trasformare il nome distinto in una stringa principale più intuitiva per le 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 serviziot proxy e la simulazione dell'identità delaccount di serviziot:

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

2. Concedi al gruppo Google o al set di entità il ruolo Creatore token account di servizio nell'account di servizio. Consulta Gestire l'accesso agli account di servizio

3. Aggiungi ACL Kafka per il account di servizio proxy. Un esempio di entità è: User:[e-mail].

4. Utilizza la simulazione dell'identità del service account nei client Kafka per autenticarti in Kafka come account di servizio. Google Cloud IAM autorizza una singola entità come membro del gruppo autorizzato a impersonare il account di servizio proxy. e Kafka autorizza ilaccount di serviziot proxy in base agli elenchi 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 del protocollo Kafka per quella risorsa. Ad esempio, un'operazione READ per il tipo di risorsa topic viene mappata ai protocolli Apache Kafka Fetch, OffsetCommit e TxnOffsetCommit.

Per concedere a un produttore principale l'accesso a un argomento, procedi nel seguente modo:

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

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

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

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

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

Per saperne di più 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 predefinito

I cluster Kafka gestiti sono configurati con allow.everyone.if.no.acl.found = true. Pertanto, per impostazione predefinita, se non sono impostate ACL su una risorsa, tutti i principal 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 ha un ACL definito e il comportamento allow.everyone.if.no.acl.found viene eliminato. Per impostazione predefinita, a qualsiasi entità non esplicitamente consentita da un'ACL ALLOW viene negato l'accesso.

Ad esempio, per impostare gli ACL su tutte le risorse del cluster per l'account di servizio [e-mail], crea le seguenti voci ACL.

Il seguente comando gcloud CLI concede a un account di servizio denominato [e-mail] l'accesso amministrativo completo (--operation=ALL) a un cluster Kafka specifico situato in una regione particolare. Questa autorizzazione consente all'account di servizio di eseguire qualsiasi operazione sul cluster da qualsiasi host.

gcloud managed-kafka acls add-acl-entry cluster \
    --principal=`User:[e-mail]` \
    --operation=ALL \
    --permission-type=ALLOW \
    --host=* \
    --cluster=CLUSTER_ID \
    --location=LOCATION

Il seguente comando gcloud CLI concede a un account di servizio denominato [e-mail] l'accesso amministrativo completo (--operation=ALL) a tutti gli argomenti all'interno di un cluster Kafka specifico che si trova in una determinata regione. Questa autorizzazione consente al account di servizio di eseguire qualsiasi operazione su tutti gli argomenti da qualsiasi host.

gcloud managed-kafka acls add-acl-entry allTopics \
    --principal=`User:[e-mail]` \
    --operation=ALL \
    --permission-type=ALLOW \
    --host=* \
    --cluster=CLUSTER_ID \
    --location=LOCATION

Il seguente comando gcloud CLI concede a un account di servizio denominato [e-mail] l'accesso amministrativo completo (--operation=ALL) a tutti i gruppi di consumatori all'interno di un cluster Kafka specifico che si trova in una regione particolare. Questa autorizzazione consente all'account di servizio di eseguire qualsiasi operazione su tutti i gruppi di consumatori da qualsiasi host.

gcloud managed-kafka acls add-acl-entry allConsumerGroups \
    --principal=`User:[e-mail]` \
    --operation=ALL \
    --permission-type=ALLOW \
    --host=* \
    --cluster=CLUSTER_ID \
    --location=LOCATION

Il seguente comando gcloud CLI concede a un account di servizio denominato [e-mail] l'accesso amministrativo completo (--operation=ALL) a tutti gli ID transazionali all'interno di un cluster Kafka specifico che si trova in una regione particolare. Questa autorizzazione consente alaccount di serviziot di eseguire qualsiasi operazione su tutti gli ID transazionali da qualsiasi host.

gcloud managed-kafka acls add-acl-entry allTransactionalIds \
    --principal=`User:[e-mail]` \
    --operation=ALL \
    --permission-type=ALLOW \
    --host=* \
    --cluster=CLUSTER_ID \
    --location=LOCATION

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

• --principal='User:[e-mail]': l'entità a cui si applica l'ACL. Il principal è un accountGoogle Cloud con il prefisso Kafka StandardAuthorizer 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 ACL con host '*'.

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

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

Configurare gli ACL

Puoi configurare gli elenchi ACL Apache Kafka con le API Managed Service per Apache Kafka ACL o con strumenti Apache Kafka open source come Apache Kafka authorizer cli kafka-acls.sh, o Admin Client.

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

• 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 della risorsa: il nome o il prefisso della risorsa a cui si applicano le voci ACL.

Una risorsa ACL 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 della risorsa dell'associazione ACL. Per saperne di più, consulta ID ACL.

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

Per saperne di più, consulta Crea un ACL Kafka gestito e Aggiungi una voce ACL Kafka gestita.

Consenti la lettura da un argomento

Per consentire ai client Apache Kafka open source in esecuzione come account di servizio [e-mail] di leggere dall'argomento topic-name, crea una voce ACL Managed Service per Apache Kafka utilizzando il comando managed-kafka acls add-acl-entry:

gcloud managed-kafka acls add-acl-entry topic/topic-name \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:[e-mail]' \
    --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 risorsa argomento specifico (letterale).

• LOCATION: la regione Google Cloud 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:[e-mail]': l'entità a cui si applica l'ACL. Il principal è un accountGoogle Cloud con il prefisso Kafka StandardAuthorizer User:.

• --operation=READ: l'operazione Kafka che viene 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 comando remove-acl-entry con gli stessi parametri.

gcloud managed-kafka acls remove-acl-entry topic/topic-name \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:[e-mail]' \
    --operation=READ \
    --permission-type=ALLOW \
    --host='*'

Consenti la scrittura in tutti gli argomenti con un prefisso comune

Per consentire ai client Apache Kafka open source in esecuzione come account di servizio [e-mail] 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:[e-mail]' \
    --operation=WRITE \
    --permission-type=ALLOW \
    --host='*'

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

• topicPrefixed/topic-prefix: specifica il pattern della risorsa Managed Service per Apache Kafka a cui vuoi concedere l'accesso. Sostituisci topic-prefix con il prefisso effettivo dei tuoi 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 progetto Google Cloud in cui si trova il cluster Managed Service per Apache Kafka.

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

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

• --principal='User:[e-mail]': l'entità a cui si applica l'ACL. Il principal è un accountGoogle Cloud con il prefisso Kafka StandardAuthorizer User:.

• --operation=WRITE: l'operazione Kafka che viene 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 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:[e-mail]' \
    --operation=WRITE \
    --permission-type=ALLOW \
    --host='*'

Nega la modifica di tutti gli argomenti

Per impedire ai client Apache Kafka open source in esecuzione come account di servizio [e-mail] di modificare tutti gli argomenti in un cluster, puoi creare una risorsa ACL Managed Service per Apache Kafka con un elenco di risorse AclEntry per negare le operazioni ALTER, ALTER_CONFIGS e DELETE su tutti gli argomenti. Questo approccio definisce lo stato richiesto in un'unica 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:[e-mail]' \
    --operation=ALTER \
    --permission-type=DENY \
    --host='*'

gcloud managed-kafka acls add-acl-entry allTopics \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:[e-mail]' \
    --operation=ALTER_CONFIGS \
    --permission-type=DENY \
    --host='*'

gcloud managed-kafka acls add-acl-entry allTopics \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:[e-mail]' \
    --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 regione Google Cloud 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:[e-mail]': specifica l'entità a cui si applica l'ACL. L'entità è un accountGoogle Cloud con il prefisso Kafka StandardAuthorizer 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 questo rifiuto si applica indipendentemente dall'host da cui ha origine la richiesta. Managed Service per Apache Kafka supporta solo ACL con host '*'.

Per rimuovere queste limitazioni, utilizza il comando remove-acl-entry per ciascuna delle voci aggiunte, utilizzando gli stessi parametri. Ad esempio, per consentire nuovamente l'eliminazione dell'argomento:

gcloud managed-kafka acls remove-acl-entry allTopics \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:[e-mail]' \
    --operation=DELETE \
    --permission-type=DENY \
    --host='*'

Risoluzione dei problemi relativi alle ACL

L'autorizzatore standard Apache Kafka scrive i log di controllo per impostazione predefinita in caso di negazione dell'autorizzazione. Se ricevi un errore di autorizzazione Kafka, puoi confermare l'entità, la risorsa e l'operazione che è stata negata cercando StandardAuthorizerData logAuditMessage nei log del cluster.

Ad esempio, ecco un log del cluster di esempio.

org.apache.kafka.metadata.authorizer.StandardAuthorizerData logAuditMessage\n
INFO: Principal = User:[e-mail] 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

• Controllo dell'accesso con IAM.

• Ruoli e autorizzazioni di Managed Service per Apache Kafka.

• Documentazione di Apache Kafka sugli ACL.

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