Ce document explique comment utiliser Google Cloud Identity and Access Management (IAM) pour contrôle des accès dans Google Cloud Managed Service for Apache Kafka.
IAM contrôle l'accès au niveau des ressources Google Cloud :
Les contrôles IAM déterminent qui peut gérer vos ressources Managed Service pour Apache Kafka, comme les clusters, les sujets ou les LCA, à l'aide des API et des outils Google Cloud . Par exemple, la consoleGoogle Cloud , gcloud CLI ou les bibliothèques clientes.
Ces contrôles déterminent également qui est autorisé à se connecter initialement à votre cluster Managed Service pour Apache Kafka lorsque vous utilisez des clients Apache Kafka standards.
Pour en savoir plus sur IAM, consultez la documentation IAM.
Présentation d'IAM
IAM vous permet d'accorder un accès précis à des ressourcesGoogle Cloud spécifiques et empêche tout accès non souhaité à d'autres ressources. IAM vous permet d'adopter le principe de sécurité du moindre privilège, qui consiste à n'accorder que l'accès nécessaire à vos ressources.
IAM vous permet de contrôler qui (comptes principaux) a accès (rôles) à quelles ressources.
Compte principal
Un compte principal peut être un compte Google (pour les utilisateurs finaux), un compte de service (pour les applications et les machines virtuelles), un groupe Google, ou un domaine Google Workspace ou Cloud Identity pouvant accéder à une ressource.
Pour en savoir plus, consultez Présentation d'IAM : comptes principaux.
Un principal spécial : l'agent du service Kafka géré
Google Cloud Managed Service pour Apache Kafka utilise un compte de service géré Google Cloud , appelé agent de service, pour accéder à vos ressources. Si vous avez activé l'API, l'agent de service est déjà créé. L'agent de service peut être identifié par son adresse e-mail : service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com.
L'agent de service Managed Service pour Apache Kafka nécessite le rôle Agent de service Managed Kafka (roles/managedkafka.serviceAgent) dans le projet pour gérer les ressources Managed Service pour Apache Kafka.
Ce rôle est automatiquement accordé lorsque vous activez l'API. Si vous révoquez ce rôle, Managed Service pour Apache Kafka ne pourra pas créer, modifier ni supprimer de clusters.
Ressource
Voici quelques exemples de ressources auxquelles vous pouvez accorder l'accès dans Managed Service pour Apache Kafka : projets, clusters, sujets et groupes de consommateurs.
Certaines méthodes d'API nécessitent des autorisations pour plusieurs ressources. Par exemple, la tâche de création d'un cluster Connect nécessite l'autorisation managedkafka.connectClusters.create sur l'emplacement parent de la ressource de cluster Connect et l'autorisation managedkafka.clusters.attachConnectCluster sur la ressource de cluster.
Rôle
Un rôle est un ensemble d'autorisations. Les autorisations déterminent les opérations autorisées sur une ressource. Lorsque vous attribuez un rôle à un compte principal, vous lui accordez toutes les autorisations contenues dans ce rôle.
Vous pouvez attribuer un ou plusieurs rôles à un compte principal.
Comme les autres produits Google Cloud , Managed Service pour Apache Kafka est compatible avec trois types de rôles :
Rôles de base : rôles très permissifs qui existaient avant la mise en place d'IAM. Pour en savoir plus sur les rôles de base, consultez la section Rôles de base.
Les rôles prédéfinis offrent un accès précis à des ressources Google Cloudspécifiques. Pour en savoir plus sur les rôles prédéfinis, consultez Rôles prédéfinis. Les rôles prédéfinis Managed Service pour Apache Kafka sont inclus dans une partie ultérieure de cette section.
Les rôles personnalisés vous aident à appliquer le principe du moindre privilège. Pour en savoir plus sur les rôles personnalisés, consultez Rôles personnalisés.
Par exemple, le rôle prédéfini Lecteur Managed Kafka (roles/managedkafka.viewer) fournit un accès en lecture seule aux ressources Managed Service pour Apache Kafka. Un compte principal doté de ce rôle peut afficher les clusters, les thèmes et les groupes de consommateurs, mais ne peut pas les créer, les mettre à jour ni les supprimer.
Pour en savoir plus sur l'attribution de rôles, consultez la documentation Accorder, modifier et révoquer les accès.
Pour déterminer les autorisations dont vous avez besoin pour une tâche spécifique, consultez la page de référence Rôles et autorisations Managed Service pour Apache Kafka.
Fonctionnement du contrôle des accès
L'autorisation d'accéder à Managed Service pour Apache Kafka à l'aide des API Google Cloud est gérée par IAM. L'autorisation d'accès à partir de clients Apache Kafka Open Source utilisant l'authentification SASL est vérifiée par IAM.
Lorsqu'un client se connecte à l'aide de SASL, IAM vérifie d'abord si le principal dispose de l'autorisation
managedkafka.clusters.connect. Si cette vérification échoue, la connexion est refusée.Lorsqu'un client se connecte à l'aide de mTLS, cette vérification initiale des autorisations IAM est ignorée, et l'autorisation est gérée exclusivement par les LCA Kafka.
Pour une sécurité complète, vous devez configurer les éléments suivants :
Autorisations IAM pour l'accès à la gestion.
Autorisations IAM pour l'accès à la connexion si vous utilisez SASL.
Listes de contrôle d'accès Kafka pour l'accès aux données et les opérations dans le cluster à partir de clients Apache Kafka Open Source, indépendamment de la méthode d'authentification.
Par exemple, supposons que vous souhaitiez empêcher un compte principal de modifier des thèmes. Pour ce faire, vous avez le choix entre deux méthodes :
Entièrement via IAM. Refusez au principal les rôles Éditeur de sujet Managed Kafka (
roles/managedkafka.topicEditor) et Client Managed Kafka (roles/managedkafka.client). Cette configuration limite complètement la modification des thèmes via les API Google Cloudet empêche tout accès à l'API Kafka à l'aide de SASL. Cette configuration n'empêche pas les connexions qui utilisent mTLS.Utiliser les LCA Kafka en association avec IAM Cette méthode est requise si le compte principal utilise mTLS ou a besoin d'un accès SASL pour d'autres opérations. Limitez les opérations suivantes à l'aide des LCA Kafka :
Créer (pour la création de thèmes) au niveau du cluster.
Alter, AlterConfigs, Delete (pour la modification et la suppression de sujets) au niveau du sujet.
Vous pouvez choisir la méthode appropriée selon que le principal a besoin d'accéder aux API Kafka et selon la méthode d'authentification utilisée.
Définir le contrôle des accès au niveau du projet
Pour définir les autorisations d'accès au niveau du projet, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.
Définir le contrôle des accès au niveau des ressources
Certaines requêtes Managed Service pour Apache Kafka, comme la création ou la mise à jour de clusters, sont des opérations de longue durée. Pour autoriser un compte principal à effectuer ces actions, accordez-lui l'accès aux ressources managedkafka.googleapis.com/Operation en plus de la ressource de cluster spécifique.
Cette configuration permet au principal d'initier l'opération et de surveiller sa progression.
Voici un exemple de condition IAM définie sur un sujet nommé "test-topic" :
{'expression': 'resource.name.endsWith('test-topic') 'title': 'SampleIAMCondition'}`.
Cet exemple montre une condition IAM qui vérifie si un nom de ressource se termine par test-topic. Si tel est le cas, la condition est true. Cette condition spécifique est intitulée SampleIAMCondition et peut être utilisée dans une stratégie IAM pour limiter l'accès à ce sujet particulier.
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. Pour accorder 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. Ce processus garantit que le principal peut lancer l'opération et surveiller sa progression.
Contrôle des accès inter-projets
Pour autoriser un client d'un autre projet à accéder à un cluster, accordez le rôle Client Managed Kafka (roles/managedkafka.client) au compte de service du client sur le projet du cluster.
Par exemple, si vous souhaitez autoriser une VM Compute Engine dans project-B à accéder à un cluster dans project-A, dans project-A, attribuez le rôle Client Kafka géré (roles/managedkafka.client) au compte de service de la VM Compute Engine dans project-B.
Étapes suivantes
Pour en savoir plus sur les concepts fondamentaux d'IAM, consultez la présentation d'IAM.
Pour en savoir plus sur les différents composants d'une stratégie IAM, consultez Stratégie IAM.
Pour découvrir comment utiliser les LCA Kafka pour l'accès aux données dans le cluster, consultez LCA Kafka.
Pour afficher la liste complète des rôles et autorisations Managed Service pour Apache Kafka, consultez Rôles et autorisations Managed Service pour Apache Kafka.