Contrôle des accès avec les LCA Kafka

Ce document explique comment utiliser les listes de contrôle d'accès (ACL) Apache Kafka pour le contrôle des accès dans Google Cloud Managed Service pour Apache Kafka.

Les ACL Apache Kafka permettent un contrôle des accès précis au sein du cluster Kafka. Managed Service pour Apache Kafka permet d'utiliser StandardAuthorizer prêt à l'emploi, qui stocke les LCA dans les métadonnées du cluster Kafka basé sur KRaft.

• Ces LCA contrôlent les utilisateurs authentifiés qui peuvent effectuer des opérations spécifiques sur des ressources Kafka spécifiques, comme produire ou consommer des messages sur un sujet.

• Ces LCA sont utiles pour contrôler les interactions avec le cluster à l'aide de clients Apache Kafka standards, qui ne sont soumis qu'à une vérification IAM au niveau du cluster pour la connexion initiale. Pour en savoir plus, consultez la page Contrôle des accès avec IAM.

Fonctionnement du contrôle des accès aux LCA Kafka

Le client interagit avec l'outil d'autorisation ACL standard de Kafka au sein du cluster. L'outil d'autorisation évalue les ACL Apache Kafka pertinentes pour autoriser des opérations spécifiques demandées par le principal, telles que la production dans un sujet ou la consommation à partir d'un groupe. Le principal utilisé pour la vérification des LCA est dérivé de l'une des méthodes d'authentification suivantes :

• SASL : compte principal IAM tel qu'une adresse e-mail de compte de service.

• mTLS : nom distinctif (DN) du certificat client, potentiellement transformé par des règles de mappage des principaux.

Pour une sécurité complète, vous devez configurer les éléments suivants :

• Autorisations IAM pour l'accès à la gestion. Pour en savoir plus, consultez la page Contrôle des accès avec IAM.

• Listes de contrôle d'accès Kafka pour les opérations et l'accès aux données dans le cluster à partir de clients Apache Kafka Open Source, indépendamment de la méthode d'authentification.

Utilisation des LCA Apache Kafka

Les liaisons ACL Apache Kafka ont le format suivant :

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

Voici une liste d'informations importantes sur le format :

• Principal(P) : identité de l'utilisateur autorisé. Il est précédé de User:.

  • Pour l'authentification SASL, il s'agit du compte principal IAM, tel que User:[e-mail].

  • Pour l'authentification mTLS, il s'agit du nom distinctif (DN) du certificat client, tel que User:CN=my-client,OU=my-org-unit. Le format exact dépend du sujet du certificat. Les règles de mappage des principaux peuvent transformer cette valeur.

• Type d'autorisation(autorisée/refusée) : indique si l'association de la LCA autorise ou refuse l'accès. Les liaisons de refus sont prioritaires.

• Opération (O) : action effectuée (lecture, écriture ou création, par exemple). Pour savoir quelles opérations s'appliquent à quelles ressources pour les différents protocoles Kafka, consultez Opérations et ressources sur les protocoles dans la documentation Apache Kafka.

• Hôte(H) : machine à partir de laquelle la requête est envoyée. Étant donné que Managed Service pour Apache Kafka traduit les adresses réseau des clients, l'utilisation d'hôtes autres que '*' n'est pas acceptée.

• Modèle de ressource(MR) : modèle utilisé pour faire correspondre des ressources spécifiques. Un modèle de ressource se compose d'un type de ressource, d'un nom de ressource et d'un type de modèle (LITERAL ou PREFIXED).

Accès par défaut

Les clusters Managed Service pour Apache Kafka fonctionnent avec la propriété Apache Kafka allow.everyone.if.no.acl.found définie sur true. La présence ou l'absence de LCA Kafka détermine directement le niveau d'accès aux ressources :

• Si aucune LCA Kafka n'est définie pour une ressource spécifique, comme un sujet, tous les principaux authentifiés y ont accès. Cette configuration permet aux clusters Managed Service pour Apache Kafka d'être immédiatement opérationnels, sans avoir à configurer les LCA.

• Dès que vous définissez un LCA Kafka pour cette ressource, l'accès devient restreint. Seuls les comptes principaux auxquels une autorisation a été explicitement accordée à l'aide d'une entrée ALLOW dans une LCA Kafka peuvent accéder aux ressources correspondantes (sauf s'ils sont spécifiquement bloqués par une entrée DENY).

Managed Service pour Apache Kafka accorde à son agent de service un accès administratif à votre cluster. Cet accès permet à l'agent de service d'effectuer les opérations demandées par l'API Managed Service pour Apache Kafka, quelles que soient les autres LCA configurées dans le cluster. Managed Service pour Apache Kafka y parvient en modifiant l'implémentation StandardAuthorizer. La modification accorde à l'agent de service des autorisations semblables à celles des super-utilisateurs, à l'exception des opérations de lecture et d'écriture. Vous ne pouvez pas modifier cette configuration.

Principaux Kafka

Les principaux Kafka pour les clusters Managed Service pour Apache Kafka sont spécifiés avec le préfixe KafkaStandardAuthorizer "User:".

• Pour SASL/IAM : le compte principal est le compteGoogle Cloud . Par exemple, pour accorder l'accès au compte de service [e-mail], utilisez le compte principal Kafka "User:[e-mail]". Les comptes principaux des LCA Kafka doivent spécifier un utilisateur, un compte de service ou un compte principal IAM individuel, mais pas un groupe ni un ensemble de comptes principaux. Les LCA Kafka ne sont pas compatibles avec la résolution des appartenances aux groupes pour les principaux Google Cloud .

• Pour mTLS : le principal est dérivé du nom distinctif de l'objet du certificat client. Exemple : User:CN=client1,OU=dev,O=MyOrg,L=City,ST=State,C=US. Vous pouvez utiliser des règles de mappage des comptes principaux mTLS pour transformer le nom unique en une chaîne de compte principal plus conviviale pour les LCA.

Pour créer une ACL qui s'applique à tous les membres d'un groupe Google ou d'un ensemble de comptes principaux, vous pouvez utiliser un compte principal de compte de service proxy et l'emprunt d'identité d'un compte de service :

1. Créez un compte de service à utiliser comme proxy pour le groupe.

2. Attribuez le rôle Créateur de jetons du compte de service au groupe Google ou à l'ensemble de comptes principaux sur le compte de service. Consultez Gérer l'accès aux comptes de service.

3. Ajoutez des LCA Kafka pour le compte de service du proxy. Voici un exemple d'entité principale : User:[e-mail].

4. Utilisez l'emprunt d'identité de compte de service dans les clients Kafka pour vous authentifier auprès de Kafka en tant que compte de service. Google Cloud IAM autorise un compte principal individuel en tant que membre du groupe autorisé à emprunter l'identité du compte de service proxy. Kafka autorise le compte de service du proxy par rapport aux LCA existantes dans le cluster.

Opérations Kafka pour les producteurs et les consommateurs

Une opération est une action effectuée sur une ressource. Pour chaque ressource, une opération est mappée à une ou plusieurs requêtes de protocole Kafka pour cette ressource. Par exemple, une opération READ pour le type de ressource topic est mappée sur les protocoles Apache Kafka Fetch, OffsetCommit et TxnOffsetCommit.

Pour accorder à un producteur principal l'accès à un sujet, procédez comme suit :

1. Sur la ressource "topic", autorisez les opérations WRITE et CREATE.

2. Si vous utilisez des ID de transaction, autorisez l'opération WRITE sur la ressource d'ID de transaction.

Pour accorder à un consommateur principal l'accès à un sujet, procédez comme suit :

1. Sur la ressource "topic", autorisez l'opération READ.

2. Sur la ressource du groupe de consommateurs, autorisez l'opération READ.

Pour en savoir plus sur les opérations valides sur les ressources compatibles avec l'API Kafka, consultez Opérations et ressources sur les protocoles dans la documentation Apache Kafka.

Configurer les LCA pour un comportement de refus par défaut

Les clusters Kafka gérés sont configurés avec allow.everyone.if.no.acl.found = true. Par conséquent, par défaut, si aucune LCA n'est définie sur une ressource, tous les comptes principaux peuvent y accéder.

Pour configurer un comportement default-deny semblable à celui d'IAM, vous pouvez d'abord configurer l'accès pour un utilisateur administrateur à toutes les ressources du cluster. Par conséquent, une LCA est définie pour chaque ressource et le comportement allow.everyone.if.no.acl.found est supprimé. Par défaut, tout compte principal non explicitement autorisé par une LCA ALLOW se voit refuser l'accès.

Par exemple, pour définir des LCA sur toutes les ressources du cluster pour le compte de service [e-mail], créez les entrées de LCA suivantes.

La commande gcloud CLI suivante accorde à un compte de service nommé [e-mail] un accès administratif complet (--operation=ALL) à un cluster Kafka spécifique situé dans une région particulière. Cette autorisation permet au compte de service d'effectuer n'importe quelle opération sur le cluster depuis n'importe quel hôte.

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

La commande gcloud CLI suivante accorde à un compte de service nommé [e-mail] un accès administratif complet (--operation=ALL) à tous les sujets d'un cluster Kafka spécifique situé dans une région particulière. Cette autorisation permet au compte de service d'effectuer n'importe quelle opération sur tous les sujets depuis n'importe quel hôte.

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

La commande gcloud CLI suivante accorde à un compte de service nommé [e-mail] un accès administratif complet (--operation=ALL) à tous les groupes de consommateurs d'un cluster Kafka spécifique situé dans une région particulière. Cette autorisation permet au compte de service d'effectuer n'importe quelle opération sur tous les groupes de consommateurs depuis n'importe quel hôte.

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

La commande gcloud CLI suivante accorde à un compte de service nommé [e-mail] un accès administratif complet (--operation=ALL) à tous les ID de transaction d'un cluster Kafka spécifique situé dans une région particulière. Cette autorisation permet au compte de service d'effectuer n'importe quelle opération sur tous les ID de transaction depuis n'importe quel hôte.

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

Voici quelques informations importantes sur les commandes :

• --principal='User:[e-mail]' : compte principal auquel s'applique la LCA. Le compte principal est un compteGoogle Cloud , avec le préfixe Kafka StandardAuthorizer User:.

• --operation=all : opération Kafka accordée, à savoir l'accès complet dans ce cas.

• --permission-type=ALLOW : cette entrée de LCA accorde l'accès.

• --host='*' : hôte à partir duquel le compte principal peut accéder à la ressource. '*' accorde l'accès depuis n'importe quel hôte. Managed Service pour Apache Kafka n'accepte que les LCA avec l'hôte '*'.

• CLUSTER_ID : nom de votre cluster Managed Service pour Apache Kafka.

• LOCATION : région Google Cloud où se trouve votre cluster Managed Service pour Apache Kafka, par exemple us-central1.

Configurer les LCA

Vous pouvez configurer les LCA Apache Kafka avec les API LCA Managed Service pour Apache Kafka ou avec des outils Apache Kafka Open Source tels que l'interface de ligne de commande de l'outil d'autorisation Apache Kafka kafka-acls.sh ou Admin Client.

Managed Service pour Apache Kafka organise les LCA par modèles de ressources Kafka. Le format de ressource est défini par les éléments suivants :

• Type de ressource : cluster, sujet, groupe de consommateurs ou ID transactionnel

• Type de modèle : littéral ou avec préfixe (toutes les ressources dont le nom commence par la chaîne fournie)

• Nom de la ressource : nom ou préfixe de la ressource à laquelle les entrées de la LCA s'appliquent.

Une ressource LCA Managed Service pour Apache Kafka représente tous les contrôle des accès configurés pour un seul modèle de ressource Kafka, sous la forme d'une liste répétée d'entrées LCA. Le nom de la ressource LCA identifie de manière unique le modèle de ressource de la liaison LCA. Pour en savoir plus, consultez ID de la LCA.

Vous pouvez gérer les LCA Managed Service pour Apache Kafka au niveau de la ressource LCA (toutes les entrées LCA pour un modèle de ressource) ou de manière incrémentielle en ajoutant et en supprimant des entrées LCA individuelles pour un modèle de ressource LCA.

Pour en savoir plus, consultez Créer une LCA Managed Kafka et Ajouter une entrée de LCA Managed Kafka.

Autoriser la lecture à partir d'un sujet

Pour autoriser les clients Apache Kafka Open Source exécutés en tant que compte de [e-mail] à lire le sujettopic-name, créez une entrée de liste de contrôle d'accès Managed Service pour Apache Kafka à l'aide de la commandemanaged-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='*'

Voici quelques informations importantes concernant cette commande :

• topic/topic-name : spécifie le sujet Managed Service pour Apache Kafka auquel vous souhaitez accorder l'accès. Remplacez topic-name par le nom réel de votre thème. Le préfixe topic/ indique que cette entrée de LCA s'applique à un modèle de ressource de sujet spécifique (littéral).

• LOCATION : région Google Cloud où se trouve votre cluster Managed Service pour Apache Kafka, par exemple us-central1.

• CLUSTER_ID : nom de votre cluster Managed Service pour Apache Kafka.

• --principal='User:[e-mail]' : compte principal auquel s'applique la LCA. Le compte principal est un compteGoogle Cloud , avec le préfixe Kafka StandardAuthorizer User:.

• --operation=READ : opération Kafka accordée, à savoir READ dans le cas présent.

• --permission-type=ALLOW : indique que cette entrée de LCA accorde l'accès.

• --host='*' : spécifie l'hôte à partir duquel le compte principal peut accéder à la ressource. '*' accorde l'accès depuis n'importe quel hôte. Managed Service pour Apache Kafka n'est compatible qu'avec les LCA avec hôte '*'.

Pour supprimer l'accès en lecture, vous pouvez utiliser la commande remove-acl-entry avec les mêmes paramètres.

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

Autoriser l'écriture dans tous les sujets ayant un préfixe commun

Pour autoriser les clients Apache Kafka Open Source s'exécutant en tant que compte de service [e-mail] à écrire dans tous les sujets dont le nom commence par le préfixe topic-prefix, ajoutez une entrée LCA Managed Kafka comme suit :

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

Voici quelques informations importantes concernant cette commande :

• topicPrefixed/topic-prefix : spécifie le modèle de ressource Managed Service pour Apache Kafka auquel vous souhaitez accorder l'accès. Remplacez topic-prefix par le préfixe réel de vos thèmes. Le préfixe topicPrefixed/ indique que cette entrée de LCA s'applique à un modèle de ressource préfixé : tous les sujets correspondant au préfixe donné.

• PROJECT : ID de votre projet Google Cloud dans lequel se trouve votre cluster Managed Service pour Apache Kafka.

• LOCATION : région Google Cloud où se trouve votre cluster Managed Service pour Apache Kafka, par exemple us-central1.

• CLUSTER_ID : nom de votre cluster Managed Service pour Apache Kafka.

• --principal='User:[e-mail]' : compte principal auquel s'applique la LCA. Le compte principal est un compteGoogle Cloud , avec le préfixe Kafka StandardAuthorizer User:.

• --operation=WRITE : opération Kafka accordée, à savoir WRITE dans le cas présent.

• --permission-type=ALLOW : cette entrée de LCA accorde l'accès.

• --host='*' : hôte à partir duquel le compte principal peut accéder à la ressource. '*' accorde l'accès depuis n'importe quel hôte. Managed Service pour Apache Kafka n'accepte que les LCA avec l'hôte '*'.

Pour supprimer l'accès en écriture pour ce compte de service, supprimez l'entrée 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='*'

Refuser la modification de tous les thèmes

Pour empêcher les clients Apache Kafka Open Source s'exécutant en tant que compte de service [e-mail] de modifier tous les sujets d'un cluster, vous pouvez créer une ressource LCA Managed Service pour Apache Kafka avec une liste de ressources AclEntry pour refuser les opérations ALTER, ALTER_CONFIGS et DELETE sur tous les sujets. Cette approche définit l'état requis dans une seule configuration.

Vous pouvez également obtenir le même résultat en ajoutant de manière impérative trois entrées ACL distinctes à l'aide de la commande gcloud managed-kafka acls add-acl-entry. Cette méthode consiste à exécuter la commande pour refuser l'accès à chacune des opérations ALTER, ALTER_CONFIGS et DELETE, comme suit :

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

Les informations suivantes s'appliquent à chacune des commandes add-acl-entry :

• allTopics : indique que cette LCA s'applique à tous les sujets du cluster Managed Service pour Apache Kafka.

• LOCATION : région Google Cloud où se trouve votre cluster Managed Service pour Apache Kafka, par exemple us-central1.

• CLUSTER_ID : nom de votre cluster Managed Service pour Apache Kafka.

• --principal='User:[e-mail]' : spécifie le compte principal auquel la LCA s'applique. Le compte principal est un compteGoogle Cloud , avec le préfixe Kafka StandardAuthorizer User:.

• --operation : spécifie l'opération Kafka refusée :

  • ALTER : inclut des actions telles que la modification du nombre de partitions ou du facteur de réplication.

  • ALTER_CONFIGS : inclut la modification des configurations au niveau des thèmes.

  • DELETE : inclut la suppression de thèmes.

• --permission-type=DENY : indique que ces entrées de LCA bloquent l'accès pour les opérations spécifiées.

• --host='*' : spécifie que ce refus s'applique quel que soit l'hôte à partir duquel la requête est envoyée. Managed Service pour Apache Kafka n'accepte que les LCA avec l'hôte '*'.

Pour supprimer ces restrictions, utilisez la commande remove-acl-entry pour chacune des entrées ajoutées, en utilisant les mêmes paramètres. Par exemple, pour autoriser à nouveau la suppression d'un sujet :

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

Résoudre les problèmes liés aux LCA

L'outil d'autorisation standard Apache Kafka écrit les journaux d'audit par défaut sur les refus d'autorisation. Si vous recevez une erreur d'autorisation Kafka, vous pouvez confirmer le compte principal, la ressource et l'opération qui ont été refusés en recherchant StandardAuthorizerData logAuditMessage dans les journaux du cluster.

Voici un exemple de journal de cluster.

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

Étapes suivantes

• Contrôle des accès avec IAM

• Rôles et autorisations Managed Service pour Apache Kafka

• Documentation Apache Kafka sur les LCA

Apache Kafka® est une marque déposée d'Apache Software Foundation ou de ses filiales aux États-Unis et/ou dans d'autres pays.