Contrôle des accès pour Managed Service pour Apache Kafka

Dans Managed Service pour Apache Kafka, vous contrôlez l'accès à vos clusters et sujets Kafka à l'aide d'une combinaison d'autorisations Identity and Access Management (IAM) et de listes de contrôle des accès d'accès (LCA) Kafka :

  • Utilisez IAM pour accorder des autorisations d'accès en gestion et pour permettre aux clients de se connecter à un cluster lors de l'utilisation de l'authentification SASL.

  • Utilisez les LCA Kafka pour l'accès aux données et les opérations à partir de clients Apache Kafka Open Source.

Cette page présente ces options de contrôle des accès.

Agent du service Kafka géré

Managed Service pour Apache Kafka utilise un agent de service pour accéder aux ressources Google Cloud. Une fois que vous avez activé l'API Managed Kafka, l'agent de service Managed Kafka est créé.

L'agent de service Managed Kafka est un compte principal dont l'identifiant est service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com, où PROJECT_NUMBER est le numéro de votre projet Google Cloud .

Cet agent de service nécessite le rôle IAM d'agent de service Managed Kafka (roles/managedkafka.serviceAgent) sur le projet. Ce rôle est automatiquement attribué lorsque vous activez l'API. Si vous révoquez ce rôle, Managed Service pour Apache Kafka ne pourra pas créer, mettre à jour ni supprimer de clusters.

Pour certaines tâches, l'agent de service Kafka géré nécessite des rôles supplémentaires. Par exemple, si vous utilisez Kafka Connect, vous devrez peut-être accorder à l'agent de service l'autorisation d'accéder aux sources et aux récepteurs, tels que Pub/Sub ou BigQuery.

Contrôle des accès pour les clients

Il existe généralement deux façons d'effectuer des opérations sur les ressources Managed Service pour Apache Kafka :

  • L'API Managed Kafka. Cette option englobe l'appel direct des API REST, ainsi que l'utilisation de Google Cloud CLI, de la console Google Cloud ou des bibliothèques clientes.

  • L'API Apache Kafka Open Source. De nombreux clients Kafka Open Source utilisent cette API.

Contrôle des accès à l'aide de l'API Managed Kafka

Lorsque vous utilisez l'API Managed Kafka, l'autorisation est effectuée par Identity and Access Management (IAM). Pour effectuer une opération sur une ressource, le compte principal doit disposer des autorisations d'API Managed Kafka requises pour cette opération. La documentation de chaque tâche répertorie les rôles IAM nécessaires pour cette tâche. Par exemple, pour autoriser un compte principal à créer des sujets Kafka, attribuez-lui le rôle Éditeur de sujet Managed Kafka.

Contrôle des accès à l'aide de l'API Apache Kafka

Les clients qui utilisent l'API Apache Kafka s'authentifient à l'aide de l'authentification SASL ou TLS mutuelle (mTLS).

  • Si un client se connecte avec SASL, le compte principal d'authentification doit disposer de l'autorisation IAM managedkafka.clusters.connect. Pour accorder cette autorisation, vous pouvez attribuer le rôle Client Managed Kafka (roles/managedkafka.client) au compte principal.

  • Si un client se connecte avec mTLS, l'autorisation managedkafka.clusters.connect n'est pas requise. À la place, les clients utilisent des certificats clients pour s'authentifier.

Une fois que le client est connecté, le service utilise des LCA Kafka pour autoriser les opérations du client, telles que la lecture ou la modification de ressources.

Contrôle des accès combiné

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

  • Autorisations IAM pour l'accès à la gestion.

  • Autorisation IAM de se connecter au cluster, si les clients utilisent SASL.

  • LCA Kafka pour l'accès aux données et les opérations au sein du cluster à partir de clients Apache Kafka Open Source, quelle que soit la méthode d'authentification.

Par exemple, supposons que vous souhaitiez empêcher un compte principal de modifier des sujets. Pour ce faire, vous devez configurer les contrôles d'accès suivants :

  • Refusez au compte principal l'autorisation managedkafka.topics.update pour l'empêcher d'utiliser l'API Managed Kafka pour mettre à jour des sujets (par exemple, à l'aide de la console Google Cloud ).

  • Vous pouvez éventuellement refuser l'autorisation managedkafka.clusters.connect au compte principal pour l'empêcher de se connecter au cluster avec l'authentification SASL.

  • Si le compte principal a besoin d'un accès SASL pour d'autres raisons, ou s'il se connecte à l'aide de mTLS, créez une LCA Kafka qui refuse les opérations ALTER, ALTER_CONFIGS et DELETE sur les sujets. Pour obtenir des exemples spécifiques, consultez Refuser la modification de tous les sujets.

Contrôle des accès au niveau des ressources

Pour limiter les autorisations IAM d'un compte principal à des ressources Managed Service pour Apache Kafka spécifiques au sein d'un projet, telles que des clusters ou des sujets individuels, utilisez des conditions IAM.

L'exemple suivant montre une condition IAM qui n'autorise l'accès que si le type de ressource est managedkafka.googleapis.com/Topic et que le nom de la ressource se termine par "test-topic" :

{
    "expression": "resource.name.endsWith(\"topic-1\") &&\nresource.type == \"managedkafka.googleapis.com/Topic\"",
    "title": "topic-1",
    "description": "Grant access only to topic-1"
}

Certaines requêtes Managed Service pour Apache Kafka, telles que la création ou la mise à jour de clusters, renvoient des opérations de longue durée. Si vous accordez l'accès au niveau du cluster, incluez l'accès à toutes les ressources de type managedkafka.googleapis.com/Operation, en plus de la condition de ressource par cluster. Cette autorisation permet au compte principal de lancer l'opération et de surveiller sa progression.

Étapes suivantes

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.