Zugriffssteuerung mit Kafka-ACLs

In diesem Dokument wird beschrieben, wie Sie Apache Kafka-Zugriffssteuerungslisten (Access Control Lists, ACLs) für die Zugriffssteuerung in Google Cloud Managed Service for Apache Kafka verwenden.

Apache Kafka-ACLs ermöglichen eine detaillierte Zugriffssteuerung im Kafka-Cluster. Managed Service for Apache Kafka ermöglicht die sofort einsatzbereite StandardAuthorizer, in der ACLs in den KRaft-basierten Kafka-Clustermetadaten gespeichert werden.

• Mit diesen ACLs wird gesteuert, welche authentifizierten Nutzer bestimmte Vorgänge für bestimmte Kafka-Ressourcen ausführen können, z. B. Nachrichten für ein Thema erstellen oder abrufen.

• Diese ACLs sind nützlich, um Interaktionen mit dem Cluster mithilfe von Standard-Apache Kafka-Clients zu steuern, die nur einer IAM-Prüfung auf Clusterebene für die erste Verbindung unterliegen. Weitere Informationen finden Sie unter Zugriffssteuerung mit IAM.

Funktionsweise der Kafka-ACL-Zugriffssteuerung

Der Client interagiert mit dem standardmäßigen ACL-Autorisierungsmodul von Kafka im Cluster. Der Authorizer wertet die relevanten Apache Kafka-ACLs aus, um bestimmte Vorgänge zu autorisieren, die vom Prinzipal angefordert werden, z. B. das Erstellen von Daten für ein Thema oder das Abrufen von Daten aus einer Gruppe. Der für die ACL-Prüfung verwendete Prinzipal wird aus einer der folgenden Authentifizierungsmethoden abgeleitet:

• SASL:Das IAM-Hauptkonto, z. B. die E-Mail-Adresse eines Dienstkontos.

• mTLS:Der Distinguished Name (DN) aus dem Clientzertifikat, der möglicherweise durch Regeln für die Prinzipalzuordnung transformiert wurde.

Für umfassende Sicherheit müssen Sie Folgendes konfigurieren:

• IAM-Berechtigungen für den Verwaltungszugriff. Weitere Informationen finden Sie unter Zugriffssteuerung mit IAM.

• Kafka-ACLs für den Datenzugriff und Vorgänge im Cluster von Open-Source-Apache Kafka-Clients, unabhängig von der Authentifizierungsmethode.

Verwendung von Apache Kafka-ACLs

Apache Kafka-ACL-Bindungen haben das folgende Format:

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

Hier finden Sie eine Liste wichtiger Informationen zum Format:

• Identität(P): Die Nutzeridentität, die autorisiert wird. Diesem wird das Präfix User: vorangestellt.

  • Bei der SASL-Authentifizierung ist dies der IAM-Prinzipal, z. B. User:[e-mail].

  • Bei der mTLS-Authentifizierung ist dies der Distinguished Name (DN) aus dem Clientzertifikat, z. B. User:CN=my-client,OU=my-org-unit. Das genaue Format hängt vom Betreff des Zertifikats ab. Mit Regeln für die Zuordnung von Identitäten kann dieser Wert transformiert werden.

• Berechtigungstyp(Zugelassen/Abgelehnt): Gibt an, ob die ACL-Bindung den Zugriff zulässt oder verweigert. Ablehnungsbindungen haben Vorrang.

• Vorgang(O): Die ausgeführte Aktion, z. B. „Lesen“, „Schreiben“ oder „Erstellen“. Informationen dazu, welche Vorgänge für welche Ressourcen für verschiedene Kafka-Protokolle gelten, finden Sie in der Apache Kafka-Dokumentation unter Operations and Resources on Protocols.

• Host(H): Der Computer, von dem die Anfrage stammt. Da Managed Service for Apache Kafka Client-Netzwerkadressen übersetzt, wird die Verwendung anderer Hosts als '*' nicht unterstützt.

• Ressourcenmuster(Resource Pattern, RP): Ein Muster, das verwendet wird, um bestimmte Ressourcen abzugleichen. Ein Ressourcenmuster besteht aus einem Ressourcentyp, einem Ressourcennamen und einem Mustertyp (LITERAL oder PREFIXED).

Standardzugriff

Managed Service for Apache Kafka-Cluster werden mit der Apache Kafka-Eigenschaft allow.everyone.if.no.acl.found auf true betrieben. Das Vorhandensein oder Fehlen von Kafka-ACLs bestimmt direkt den Zugriff auf Ressourcen:

• Wenn für eine bestimmte Ressource wie ein Thema keine Kafka-ACLs definiert sind, erhalten alle authentifizierten Principals Zugriff darauf. Mit dieser Konfiguration können Managed Service for Apache Kafka-Cluster sofort verwendet werden, ohne dass ACLs konfiguriert werden müssen.

• Sobald Sie eine Kafka-ACL für diese Ressource definieren, wird der Zugriff eingeschränkt. Nur Hauptkonten, denen explizit die Berechtigung über einen ALLOW-Eintrag in einer Kafka-ACL gewährt wurde, können auf entsprechende Ressourcen zugreifen, sofern sie nicht durch einen DENY-Eintrag blockiert werden.

Managed Service for Apache Kafka gewährt seinem Dienst-Agent Administratorzugriff auf Ihren Cluster. Dieser Zugriff ermöglicht dem Dienst-Agent, Vorgänge auszuführen, die von der Managed Service for Apache Kafka API angefordert werden, unabhängig von anderen im Cluster konfigurierten ACLs. Managed Service for Apache Kafka erreicht dies durch die Änderung der StandardAuthorizer-Implementierung. Durch die Änderung erhält der Service-Agent Berechtigungen, die denen von Superusern ähneln, mit Ausnahme von Lese- und Schreibvorgängen. Sie können diese Konfiguration nicht ändern.

Kafka-Principals

Kafka-Principals für Managed Service for Apache Kafka-Cluster werden mit dem Präfix "User:" des Kafka StandardAuthorizer angegeben.

• Für SASL/IAM:Das Prinzipal ist dasGoogle Cloud -Konto. Wenn Sie beispielsweise Zugriff auf das Dienstkonto [e-mail] gewähren möchten, verwenden Sie das Kafka-Hauptkonto "User:[e-mail]". Für Kafka-ACL-Hauptkonten muss ein Nutzer, ein Dienstkonto oder ein einzelnes IAM-Hauptkonto angegeben werden, aber keine Gruppe oder Hauptkontogruppe. Kafka-ACLs unterstützen die Auflösung von Gruppenmitgliedschaften für Google Cloud -Principals nicht.

• Für mTLS:Der Principal wird aus dem Betreff-DN (Distinguished Name) des Clientzertifikats abgeleitet. Beispiel: User:CN=client1,OU=dev,O=MyOrg,L=City,ST=State,C=US Mit mTLS-Regeln für die Zuordnung von Identitäten können Sie den DN in einen nutzerfreundlicheren Identitätsstring für ACLs umwandeln.

Wenn Sie eine ACL erstellen möchten, die für alle Mitglieder einer Google-Gruppe oder einer Prinzipalgruppe gilt, können Sie einen Proxy-Dienstkonto-Prinzipal und die Identitätsübernahme des Dienstkontos verwenden:

1. Erstellen Sie ein Dienstkonto, das als Proxy für die Gruppe verwendet werden soll.

2. Weisen Sie der Google-Gruppe oder dem Hauptkonto die Rolle Ersteller von Dienstkonto-Tokens für das Dienstkonto zu. Weitere Informationen finden Sie unter Zugriff auf Dienstkonten verwalten.

3. Fügen Sie Kafka-ACLs für das Proxy-Dienstkonto hinzu. Ein Beispiel für ein Hauptkonto wäre: User:[e-mail].

4. Verwenden Sie die Identitätsübernahme von Dienstkonten in Kafka-Clients, um sich als Dienstkonto bei Kafka zu authentifizieren. Google Cloud IAM autorisiert ein einzelnes Hauptkonto als Mitglied der Gruppe, die die Identität des Proxy-Dienstkontos übernehmen darf. Kafka autorisiert das Proxy-Dienstkonto anhand der vorhandenen ACLs im Cluster.

Kafka-Vorgänge für Produzenten und Nutzer

Ein Vorgang ist eine Aktion, die für eine Ressource ausgeführt wird. Für jede Ressource wird ein Vorgang einer oder mehreren Kafka-Protokollanfragen für diese Ressource zugeordnet. Ein READ-Vorgang für den Ressourcentyp topic wird beispielsweise den Apache Kafka-Protokollen Fetch, OffsetCommit und TxnOffsetCommit zugeordnet.

So gewährst du einem Hauptproduzenten Zugriff auf ein Thema:

1. Lassen Sie für die Themenressource die Vorgänge WRITE und CREATE zu.

2. Wenn Sie Transaktions-IDs verwenden, müssen Sie für die Transaktions-ID-Ressource den Vorgang WRITE zulassen.

So gewähren Sie einem Hauptkonto Zugriff auf ein Thema:

1. Erlauben Sie für die Themenressource den Vorgang READ.

2. Erlauben Sie den Vorgang READ für die Ressource der Nutzergruppe.

Weitere Informationen zu den gültigen Vorgängen für Ressourcen, die von der Kafka API unterstützt werden, finden Sie in der Apache Kafka-Dokumentation unter Operations and Resources on Protocols.

ACLs für das Standardablehnungsverhalten konfigurieren

Verwaltete Kafka-Cluster werden mit allow.everyone.if.no.acl.found = true konfiguriert. Wenn für eine Ressource keine ACLs festgelegt sind, können standardmäßig alle Hauptkonten auf die Ressource zugreifen.

Wenn Sie ein default-deny-Verhalten konfigurieren möchten, das dem in IAM ähnelt, können Sie zuerst den Zugriff für einen Administratornutzer auf alle Ressourcen im Cluster konfigurieren. Daher erhält jede Ressource eine ACL und das allow.everyone.if.no.acl.found-Verhalten wird unterdrückt. Standardmäßig wird jedem Hauptkonto, das nicht explizit durch eine ALLOW-ACL zugelassen ist, der Zugriff verweigert.

Wenn Sie beispielsweise ACLs für alle Ressourcen im Cluster für das Dienstkonto [e-mail] festlegen möchten, erstellen Sie die folgenden ACL-Einträge.

Mit dem folgenden gcloud CLI-Befehl wird einem Dienstkonto mit dem Namen [e-mail] der vollständige Administratorzugriff (--operation=ALL) auf einen bestimmten Kafka-Cluster in einer bestimmten Region gewährt. Mit dieser Berechtigung kann das Dienstkonto von jedem Host aus beliebige Vorgänge für den Cluster ausführen.

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

Mit dem folgenden gcloud CLI-Befehl wird einem Dienstkonto mit dem Namen [e-mail]--operation=ALL vollständiger Administratorzugriff auf alle Themen in einem bestimmten Kafka-Cluster in einer bestimmten Region gewährt. Mit dieser Berechtigung kann das Dienstkonto beliebige Vorgänge für alle Themen von jedem Host aus ausführen.

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

Mit dem folgenden gcloud CLI-Befehl wird einem Dienstkonto mit dem Namen [e-mail] der vollständige Administratorzugriff (--operation=ALL) auf alle Verbrauchergruppen in einem bestimmten Kafka-Cluster in einer bestimmten Region gewährt. Mit dieser Berechtigung kann das Dienstkonto beliebige Vorgänge für alle Verbrauchergruppen von einem beliebigen Host aus ausführen.

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

Mit dem folgenden gcloud-Befehlszeilenbefehl wird einem Dienstkonto mit dem Namen [e-mail] der vollständige Administratorzugriff (--operation=ALL) auf alle Transaktions-IDs in einem bestimmten Kafka-Cluster in einer bestimmten Region gewährt. Mit dieser Berechtigung kann das Dienstkonto beliebige Vorgänge für alle Transaktions-IDs von einem beliebigen Host aus ausführen.

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

Im Folgenden finden Sie eine Liste wichtiger Informationen zu den Befehlen:

• --principal='User:[e-mail]': Das Hauptkonto, auf das sich die ACL bezieht. Das Hauptkonto ist einGoogle Cloud -Konto mit dem Kafka StandardAuthorizer-Präfix User:.

• --operation=all: Der gewährte Kafka-Vorgang, in diesem Fall vollständiger Zugriff.

• --permission-type=ALLOW: Dieser ACL-Eintrag gewährt Zugriff.

• --host='*': Der Host, über den das Hauptkonto auf die Ressource zugreifen kann. '*' gewährt Zugriff von jedem Host. Managed Service for Apache Kafka unterstützt nur ACLs mit dem Host '*'.

• CLUSTER_ID: der Name Ihres Managed Service for Apache Kafka-Clusters.

• LOCATION: Die Google Cloud Region, in der sich Ihr Managed Service for Apache Kafka-Cluster befindet, z. B. us-central1.

ACLs konfigurieren

Sie können Apache Kafka-ACLs mit den Managed Service for Apache Kafka-ACL-APIs oder mit Open-Source-Apache Kafka-Tools wie der Apache Kafka-Autorisierungs-CLI kafka-acls.sh oder Admin Client konfigurieren.

In Managed Service for Apache Kafka werden ACLs nach Kafka-Ressourcenmustern organisiert. Das Ressourcenmuster wird durch Folgendes definiert:

• Ressourcentyp: Cluster, Thema, Nutzergruppe oder Transaktions-ID

• Mustertyp: Literal oder mit Präfix (alle Ressourcen, deren Name mit dem angegebenen String beginnt)

• Ressourcenname: Der Ressourcenname oder das Präfix, auf das sich die ACL-Einträge beziehen.

Eine ACL-Ressource für Managed Service for Apache Kafka stellt die gesamte Zugriffssteuerung dar, die für ein einzelnes Kafka-Ressourcenmuster als wiederholte Liste von ACL-Einträgen konfiguriert ist. Der Name der ACL-Ressource identifiziert das Ressourcenmuster der ACL-Bindung eindeutig. Weitere Informationen finden Sie unter ACL-ID.

Sie können ACLs für Managed Service for Apache Kafka auf ACL-Ressourcenebene (alle ACL-Einträge für ein Ressourcenmuster) oder inkrementell verwalten, indem Sie einzelne ACL-Einträge für ein ACL-Ressourcenmuster hinzufügen und entfernen.

Weitere Informationen finden Sie unter Managed Kafka-ACL erstellen und Managed Kafka-ACL-Eintrag hinzufügen.

Lesen aus einem Thema erlauben

Damit Open-Source-Apache Kafka-Clients, die als Dienstkonto [e-mail] ausgeführt werden, aus dem Thema topic-name lesen können, erstellen Sie einen ACL-Eintrag für Managed Service for Apache Kafka mit dem managed-kafka acls add-acl-entry-Befehl:

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='*'

Im Folgenden finden Sie eine Liste wichtiger Informationen zum Befehl:

• topic/topic-name: Gibt das Managed Service for Apache Kafka-Thema an, für das Sie Zugriff gewähren möchten. Ersetzen Sie topic-name durch den tatsächlichen Namen Ihres Themas. Das Präfix topic/ gibt an, dass dieser ACL-Eintrag für ein bestimmtes (wörtliches) Themenressourcenmuster gilt.

• LOCATION: Die Google Cloud Region, in der sich Ihr Managed Service for Apache Kafka-Cluster befindet, z. B. us-central1.

• CLUSTER_ID: der Name Ihres Managed Service for Apache Kafka-Clusters.

• --principal='User:[e-mail]': Das Hauptkonto, auf das sich die ACL bezieht. Das Hauptkonto ist einGoogle Cloud -Konto mit dem Kafka StandardAuthorizer-Präfix User:.

• --operation=READ: Der Kafka-Vorgang, für den die Berechtigung erteilt wird. In diesem Fall ist das READ.

• --permission-type=ALLOW: Gibt an, dass dieser ACL-Eintrag Zugriff gewährt.

• --host='*': Gibt den Host an, über den das Hauptkonto auf die Ressource zugreifen kann. '*' gewährt Zugriff von jedem Host. Managed Service for Apache Kafka unterstützt nur ACLs mit dem Host '*'.

Wenn Sie den Lesezugriff entfernen möchten, können Sie den Befehl remove-acl-entry mit denselben Parametern verwenden.

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='*'

Schreiben zu allen Themen mit einem gemeinsamen Präfix zulassen

Damit Open-Source-Apache Kafka-Clients, die als Dienstkonto [e-mail] ausgeführt werden, in alle Themen schreiben können, deren Name mit dem Präfix topic-prefix beginnt, fügen Sie einen Managed Kafka-ACL-Eintrag wie folgt hinzu:

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='*'

Im Folgenden finden Sie eine Liste wichtiger Informationen zum Befehl:

• topicPrefixed/topic-prefix: Gibt das Managed Service for Apache Kafka-Ressourcenmuster an, für das Sie Zugriff gewähren möchten. Ersetzen Sie topic-prefix durch das tatsächliche Präfix Ihrer Themen. Das Präfix topicPrefixed/ gibt an, dass dieser ACL-Eintrag für ein Ressourcenmuster mit Präfix gilt: alle Themen, die dem angegebenen Präfix entsprechen.

• PROJECT: Die ID Ihres Google Cloud -Projekts, in dem sich Ihr Managed Service for Apache Kafka-Cluster befindet.

• LOCATION: Die Google Cloud Region, in der sich Ihr Managed Service for Apache Kafka-Cluster befindet, z. B. us-central1.

• CLUSTER_ID: der Name Ihres Managed Service for Apache Kafka-Clusters.

• --principal='User:[e-mail]': das Konto, für das die ACL gilt. Das Hauptkonto ist einGoogle Cloud -Konto mit dem Kafka StandardAuthorizer-Präfix User:.

• --operation=WRITE: Der Kafka-Vorgang, für den die Berechtigung erteilt wird. In diesem Fall ist das WRITE.

• --permission-type=ALLOW: Dieser ACL-Eintrag gewährt Zugriff.

• --host='*': Der Host, über den das Hauptkonto auf die Ressource zugreifen kann. '*' gewährt Zugriff von jedem Host. Managed Service for Apache Kafka unterstützt nur ACLs mit dem Host '*'.

So entfernen Sie den Schreibzugriff für dieses Dienstkonto:

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='*'

Änderung aller Themen ablehnen

Damit Open-Source-Apache Kafka-Clients, die als Dienstkonto [e-mail] ausgeführt werden, nicht alle Themen in einem Cluster ändern können, können Sie eine Managed Service for Apache Kafka-ACL-Ressource mit einer Liste von AclEntry-Ressourcen erstellen, um die Vorgänge ALTER, ALTER_CONFIGS und DELETE für alle Themen zu verweigern. Bei diesem Ansatz wird der erforderliche Status in einer einzelnen Konfiguration definiert.

Alternativ können Sie dasselbe Ergebnis erzielen, indem Sie imperativ drei separate ACL-Einträge mit dem Befehl gcloud managed-kafka acls add-acl-entry hinzufügen. Bei dieser Methode wird der Befehl zum Verweigern des Zugriffs auf die einzelnen Vorgänge ALTER, ALTER_CONFIGS und DELETE ausgeführt:

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='*'

Die folgenden Informationen gelten für jeden der add-acl-entry-Befehle:

• allTopics: Gibt an, dass diese ACL für alle Themen im Managed Service for Apache Kafka-Cluster gilt.

• LOCATION: die Google Cloud -Region, in der sich Ihr Managed Service for Apache Kafka-Cluster befindet, z. B. us-central1.

• CLUSTER_ID: der Name Ihres Managed Service for Apache Kafka-Clusters.

• --principal='User:[e-mail]': Gibt das Hauptkonto an, für das die ACL gilt. Das Hauptkonto ist einGoogle Cloud -Konto mit dem Kafka-Präfix StandardAuthorizer User:.

• --operation: Gibt den verweigerten Kafka-Vorgang an:

  • ALTER: umfasst Aktionen wie das Ändern der Anzahl der Partitionen oder des Replikationsfaktors.

  • ALTER_CONFIGS: Dazu gehört auch das Ändern von Konfigurationen auf Themenebene.

  • DELETE: Dazu gehört auch das Löschen von Themen.

• --permission-type=DENY: Gibt an, dass diese ACL-Einträge den Zugriff für die angegebenen Vorgänge blockieren.

• --host='*': Gibt an, dass diese Ablehnung unabhängig vom Host gilt, von dem die Anfrage stammt. Managed Service for Apache Kafka unterstützt nur ACLs mit dem Host '*'.

Um diese Einschränkungen zu entfernen, verwenden Sie für jeden der hinzugefügten Einträge den Befehl remove-acl-entry mit denselben Parametern. So erlauben Sie beispielsweise das Löschen von Themen wieder:

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

Fehlerbehebung bei ACLs

Der Apache Kafka Standard Authorizer schreibt standardmäßig Audit-Logs für Autorisierungsverweigerungen. Wenn Sie einen Kafka-Autorisierungsfehler erhalten, können Sie das Hauptkonto, die Ressource und den Vorgang, der abgelehnt wurde, bestätigen, indem Sie in den Clusterlogs nach StandardAuthorizerData logAuditMessage suchen.

Hier ist ein Beispiel für ein Clusterlog.

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

Nächste Schritte

• Zugriffssteuerung mit IAM

• Rollen und Berechtigungen für Managed Service for Apache Kafka

• Apache Kafka-Dokumentation zu ACLs

Apache Kafka® ist eine eingetragene Marke der Apache Software Foundation oder deren Tochtergesellschaften in den USA und/oder anderen Ländern.