Gestion de l'authentification auprès de vos instances Event Streams

Event Streams prend en charge deux mécanismes SASL (Simple Authentication and Security Layer) comme méthodes d'authentification pour les instances Event Streams par défaut: PLAIN et OAUTHBEARER.

Le client Kafka configuré avec SASL PLAIN utilise une clé d'API IAM en tant que mot de passe en texte en clair dans le processus d'authentification, Event Streams envoie la clé d'API à IAM pour vérification. Une fois authentifié, ce client reste connecté et ne nécessite pas de nouvelle authentification tant qu'il n'est pas déconnecté et qu'il ne souhaite pas se reconnecter.

Le client Kafka configuré avec SASL OAUTHBEARER utilise le jeton d'accès IAM dans le processus d'authentification, Event Streams vérifie le jeton via la clé publique IAM. Etant donné qu'un jeton d'accès IAM a un délai d'expiration (généralement 1 heure), le client Kafka est requis pour générer à nouveau un nouveau jeton et passer à nouveau par le processus d'authentification lorsque le délai d'expiration du jeton précédent approche. Cette approche offre une meilleure sécurité par rapport à SASL PLAIN de deux manières:

  1. La clé d'API reste toujours côté client pour générer le jeton d'accès et n'est plus envoyée aux courtiers Kafka sur le réseau, ce qui supprime le risque d'exposition à la clé d'API.
  2. Le processus d'authentification se produit régulièrement lorsque le jeton d'accès arrive à expiration, ce qui réduit le risque d'exposition du jeton.

Pour une authentification plus sécurisée, SASL OAUTHBEARER est la seule méthode d'authentification recommandée pour les clients Kafka. Voir Configuration de votre client API Kafka pour savoir comment configurer SASL OAUTHBEARER dans les clients Kafka.

Les utilisateurs d'entreprise ont la possibilité de désactiver SASL PLAIN dans leurs instances d'entreprise. Utilisez la commande suivante :

ibmcloud resource service-instance-update <instance-name> -p '{"iam_token_only":true}'

Connexion à Event Streams

Pour plus d'informations sur l'obtention de données d'identification de clé de sécurité pour une application externe, voir Connexion à Event Streams.

Gestion de l'autorisation pour vos ressources Event Streams

Vous pouvez sécuriser vos ressources Event Streams de manière très affinée afin de gérer l'accès que vous voulez accorder à chaque ressource pour chaque utilisateur.

Lorsque vous modifiez des règles et des autorisations IAM, il faut parfois plusieurs minutes pour qu'elles soient répercutées dans le service sous-jacent.

Que puis-je sécuriser ?

Dans Event Streams, vous disposez d'un accès sécurisé aux ressources suivantes :

  • Cluster (cluster) : vous pouvez contrôler les applications et les utilisateurs qui peuvent se connecter au service.
  • Sujets (sujet): Vous pouvez contrôler la capacité des utilisateurs et des applications à créer, supprimer, lire et écrire dans une rubrique.
  • Groupes de consommateurs (groupe) : Vous pouvez contrôler la capacité d'une application à rejoindre un groupe de consommateurs.
  • Transactions de producteur (txnid) : Vous pouvez contrôler la capacité d'utiliser la fonction de producteur transactionnel dans Kafka (c'est-à-dire, une seule et unique écriture atomique sur plusieurs partitions).

Les niveaux d'accès (également appelés rôles) que vous pouvez attribuer à un utilisateur pour chaque ressource sont les suivants.

Exemple de rôles et d'actions des utilisateurs Event Streams
Rôle d'accès Description des actions Exemples d'actions
Lecteur Exécuter des actions en lecture seule dans Event Streams, telles que l'affichage des ressources. Autoriser une application à se connecter à un cluster en affectant un accès en lecture au type de ressource de cluster.
Auteur Les auteurs disposent de droits supérieurs à ceux des lecteurs, qui leur permettent notamment d'éditer des ressources Event Streams. Autoriser une application à produire dans des rubriques en affectant un accès en écriture aux types de ressource de rubrique et de nom de rubrique.
Responsable Les responsables disposent de droits supérieurs à ceux des auteurs leur permettant d'accomplir des actions privilégiées. Ils autorisent en plus la création et l'édition de ressources Event Streams. Accorder un accès complet à toutes les ressources affectant l'accès Responsable à l'instance Event Streams.

Comment affecter un accès

Les règles Cloud Identity and Access Management (IAM) sont jointes aux ressources à contrôler. Chaque politique définit le niveau d'accès qu'un utilisateur particulier doit avoir et à quelle ressource ou ensemble de ressources. Une règle est constituée des informations suivantes :

  • Le type de service auquel s'applique la règle. Par exemple, Event Streams. Vous pouvez définir la portée d'une règle de manière à y inclure tous les types de service.
  • L'instance de service à sécuriser. Vous pouvez définir la portée d'une règle de manière à y inclure toutes les instances d'un type de service.
  • Le type de ressource à sécuriser. Les valeurs valides sont cluster, topic, group, schema ou txnid. La spécification du type est facultative. Si vous n'indiquez aucun type, la règle s'applique alors à toutes les ressources de l'instance de service. Si vous souhaitez spécifier plus d'un type de ressource, vous devez créer une règle par ressource.
  • La ressource à sécuriser. Spécifiez pour les ressources de type topic, group, schema et txnid. Si vous n'indiquez pas de ressource, la règle s'applique à toutes les ressources du type spécifié dans l'instance de service.
  • Le rôle attribué à l'utilisateur. Par exemple, Lecteur, Auteur ou Responsable.

Pour plus d'informations sur IAM, voir IBM Cloud Identity and Access Management.

Pour un exemple de définition de stratégies, voir IBM Cloud IAM Service IDs and API Keys.

Utilisation de caractères génériques

Vous pouvez tirer parti de la fonction d'utilisation de caractères génériques IAM afin de définir des règles pour des groupes de ressources sur Event Streams. Par exemple, si vous donnez à toutes vos rubriques des noms tels que Dept1_Topic1 et Dept1_Topic2, vous pouvez définir des politiques pour les rubriques qui s'appellent Dept1_* et ces politiques sont appliquées à toutes les rubriques ayant ce préfixe. Pour plus d'informations, voir Attribution d'un accès à l'aide de règles de caractères génériques.

Quels sont les paramètres de sécurité par défaut ?

Par défaut, à la mise à disposition de Event Streams, le rôle de responsable sur toutes les ressources de l'instance est accordé à l'utilisateur qui a procédé à la mise à disposition. En outre, tout utilisateur ayant un rôle de gestionnaire pour "Tous" les services ou "Toutes" les instances de service Event Streams dans le même compte dispose également d'un accès complet.

Vous pouvez ensuite appliquer d'autres règles pour étendre l'accès à d'autres utilisateurs. Vous pouvez définir l'étendue d'une règle pour qu'elle s'applique à Event Streams dans son intégralité ou à des ressources individuelles au sein de Event Streams. Pour plus d'informations, voir Actions communes.

Seuls les utilisateurs ayant un rôle d'administration pour un compte peuvent attribuer des règles aux utilisateurs. Affectez des règles à l'aide du tableau de bord IBM Cloud ou à l'aide des commandes ibmcloud.

Actions communes

Les tableaux suivants récapitulent certaines actions Event Streams communes et l'accès que vous devez affecter.

Exigences du cluster

En contrôlant l'accès à la ressource de cluster, vous pouvez déterminer les applications et les utilisateurs qui peuvent se connecter au service. Outre les règles requises pour les types de ressource ci-dessous, l'accès à ResourceType: Cluster et à Role: Reader, Writer, Manager est requis.

Actions du producteur

Le tableau suivant décrit les rôles et les besoins en ressources requis par un utilisateur ou une application qui génère des messages dans Event Streams. Outre les règles requises pour ce type de ressource, l'accès à ResourceType: Cluster et à Role: Reader, Writer, Manager est requis.

Actions des producteurs
Actions du producteur Topic Groupe txnid
Envoyer un message à un sujet. Auteur Auteur [1]
Permettre à une application de produire sur un sujet de manière transactionnelle. Auteur Lecteur Auteur
Initialisez une transaction. Auteur
Validation d'une transaction. Auteur Auteur
Abandonner une transaction. Auteur
Envoyer des décalages à une transaction. Lecteur Auteur

Actions de consommateur

Le tableau suivant décrit les rôles et les besoins en ressources requis par un utilisateur ou une application qui consomme des messages provenant de Event Streams. Outre les règles requises pour ce type de ressource, l'accès à ResourceType: Cluster et à Role: Reader, Writer, Manager est requis.

Actions des consommateurs
Actions de consommateur Topic Groupe txnid
Permettre à une application de consommer un sujet (groupe de consommateurs). Lecteur Lecteur [2]
Permettre à une application de se connecter et de consommer à partir d'un sujet spécifique (pas de groupe de consommateurs). Lecteur
Permettre à une application de se connecter et de consommer à partir de n'importe quel sujet (pas de groupe de consommateurs). Lecteur
Utilisez Kafka Streams. Responsable Lecteur
Supprimer le groupe de consommateurs. Responsable
Assigner Lecteur
Validation asynchrone. Lecteur Lecteur
Valider la synchronisation. Lecteur Lecteur
Appliquer le rééquilibrage. Lecteur
Interrogation. Lecteur
Abonnez-vous. Lecteur
Désabonnez-vous. Lecteur Auteur

Actions d'administration

Outre les règles requises pour ce type de ressource, l'accès à ResourceType: Cluster et à Role: Reader, Writer, Manager est requis.

Actions de l'administration
Actions d'administration Topic Groupe txnid
Modifier les configurations de rubrique. Responsable
Modifier les décalages de groupe de consommateurs. Lecteur Lecteur
Créez des partitions. Responsable
Créez des rubriques. Responsable
Supprimer les décalages de groupe de consommateurs. Lecteur Responsable
Supprimer des groupes de consommateurs. Responsable
Supprimer des enregistrements. Responsable
Supprimer des rubriques. Responsable
Décrivez les producteurs. Lecteur
Producteurs de clôtures. Auteur
Modifiez de manière incrémentielle les configurations de rubrique. Responsable
Supprimez des membres du groupe de consommateurs. Lecteur

Actions de registre de schéma

Avec les actions Schema Registry, vous pouvez modifier la version du schéma, par exemple créer, mettre à jour et supprimer des artefacts ou des versions d'artefact (plan Enterprise uniquement). Artefact est le terme utilisé par Event Streams pour décrire les schémas associés, souvent associés à et utilisés par une rubrique Kafka particulière. Le terme sujet est souvent utilisé pour décrire le même concept. Pour plus d'informations, voir Utilisation du registre de schéma Event Streams. Outre les règles requises pour ce type de ressource, l'accès à ResourceType: Cluster et à Role: Reader, Writer, Manager est requis.

Actions du registre des schémas
Actions de registre de schéma Schéma
Obtenir l'artefact le plus récent. Lecteur
Répertorier les versions. Lecteur
Obtenir la version. Lecteur
Obtenir les métadonnées par contenu. Lecteur
Obtenir des métadonnées. Lecteur
Obtenir les métadonnées de version. Lecteur
Obtenez la chaîne de schéma identifiée par l'ID d'entrée. Lecteur
Extrayez uniquement le schéma identifié par l'ID d'entrée. Lecteur
Obtenez les paires objet-version identifiées par l'ID d'entrée. Lecteur
Obtenir une liste des versions enregistrées sous le sujet spécifié. Lecteur
Obtenir la règle de compatibilité d'artefact. Lecteur
Obtenez une version spécifique du schéma enregistré sous ce sujet. Lecteur
Obtenir le schéma pour la version spécifiée de ce sujet. Lecteur
Enregistre un nouveau schéma sous le sujet spécifié (si la version existe déjà). Lecteur
Vérifiez si un schéma a déjà été enregistré sous le sujet spécifié. Lecteur
Obtenez la liste des ID des schémas qui font référence au schéma avec le sujet et la version donnés. Lecteur
Testez le schéma d'entrée par rapport à une version particulière du schéma d'un sujet à des fins de compatibilité. Lecteur
Effectuez une vérification de compatibilité du schéma par rapport à une ou plusieurs versions du sujet. Lecteur
Obtenir le niveau de compatibilité pour un sujet. Lecteur
Enregistre un nouveau schéma sous le sujet spécifié (si la version doit être créée). Auteur
Créer un artefact. Auteur
Mettre à jour l'artefact. Auteur
Désactivez l'artefact. Auteur
Créer une version. Auteur
Supprimer la version. Responsable
Mettre à jour l'état de l'artefact. Responsable
Mettre à jour l'état de la version. Responsable
Supprimer l'artefact. Responsable
Créer une règle de compatibilité d'artefact. Responsable
Mettre à jour la règle de compatibilité des artefacts. Responsable
Mettre à jour le niveau de compatibilité pour le sujet spécifié. Responsable
Supprimer la règle de compatibilité d'artefact. Responsable
Supprime le sujet spécifié et son niveau de compatibilité associé s'il est enregistré. Responsable
Supprimez une version spécifique du schéma enregistré sous ce sujet. Responsable
Supprime la configuration de niveau de compatibilité de niveau de sujet spécifiée et rétablit la valeur par défaut globale. Responsable
Mettez à jour la règle de compatibilité globale. [3]
Mettez à jour le niveau de compatibilité global. [4]

Actions de compatibilité de registre de schéma

Pour l'interopérabilité avec des applications existantes, le registre de schéma Event Streams prend en charge un sous-ensemble de l'API Confluent Schema Registry v7.2. Pour effectuer ces actions, vous devez disposer de l'accès au niveau de la ressource suivant.

Tableau des actions de compatibilité
Actions de compatibilité de registre de schéma Schéma
Obtenez la chaîne de schéma identifiée par l'ID d'entrée. Lecteur
Extrait uniquement le schéma identifié par l'ID d'entrée. Lecteur
Obtenez les types de schéma qui sont enregistrés avec Schema Registry.
Obtenez les paires objet-version identifiées par l'ID d'entrée. Lecteur
Obtenir une liste des sujets enregistrés.
Obtenir une liste des versions enregistrées sous le sujet spécifié. Lecteur
Supprime le sujet spécifié et son niveau de compatibilité associé s'il est enregistré. Responsable
Obtenez une version spécifique du schéma enregistré sous ce sujet. Lecteur
Obtenir le schéma pour la version spécifiée de ce sujet. Lecteur
Enregistre un nouveau schéma sous le sujet spécifié. Lecteur / Auteur [5]
Vérifiez si un schéma a déjà été enregistré sous le sujet spécifié. Lecteur
Supprime une version spécifique du schéma enregistré sous ce sujet. Responsable
Obtenez la liste des ID des schémas qui font référence au schéma avec le sujet et la version donnés. Lecteur
Testez le schéma d'entrée par rapport à une version particulière du schéma d'un sujet à des fins de compatibilité. Lecteur
Effectuez une vérification de compatibilité du schéma par rapport à une ou plusieurs versions du sujet. Lecteur
Mettez à jour le niveau de compatibilité globale. [6]
Obtenir le niveau de compatibilité global.
Mettre à jour le niveau de compatibilité pour le sujet spécifié. Responsable
Obtenir le niveau de compatibilité pour un sujet. Lecteur
Supprime la configuration de niveau de compatibilité de niveau de sujet spécifiée et rétablit la valeur par défaut globale. Responsable

Gestion de l'accès au registre de schémas

Le modèle d'autorisation pour le registre des schémas utilise le même style de politiques que celles décrites dans la section Gestion des autorisations pour vos ressources Event Streams de ce document.

Ressources IAM

Avec le nouveau type de ressource schema IAM, il est possible de créer des politiques qui contrôlent l'accès en utilisant différents degrés de granularité, comme dans les exemples suivants.

  • Un schéma spécifique.
  • Un ensemble de schémas sélectionnés par une expression générique.
  • Tous les schémas stockés par une instance d'IBM Event Streams.
  • Tous les schémas stockés par toutes les instances d'IBM Event Streams dans un compte.

Event Streams dispose déjà du concept de type de ressource de cluster. Il est utilisé pour contrôler tous les accès à l'instance de service, le rôle minimum de lecteur étant requis pour accéder à tout point de terminaison Kafka ou HTTPS. Cette utilisation du type de ressource cluster s'applique également au registre des schémas, où un rôle minimum de lecteur est requis pour accéder au registre.

Exemples de scénarios d'autorisation

Le tableau suivant décrit quelques exemples de scénarios d'interaction avec le Event Streams Ainsi que les rôles requis par les acteurs concernés. Le processus de gestion des schémas est géré indépendamment du déploiement d'applications. Des politiques sont donc nécessaires à la fois pour le service ID qui gère les schémas dans le registre et pour l'application qui se connecte au registre.

Exemples de scénarios d'autorisation
Scénario Rôle de personne ou de processus Ressource de personne ou de processus Rôle d"application Ressource de l'application
Les nouvelles versions de schéma sont placées dans le registre par une personne ou un processus distinct des applications qui utilisent les schémas. Reader
Writer
cluster
schema
Reader
Reader
cluster
schema
L'ajout d'un schéma au registre doit spécifier une règle par défaut qui contrôle la manière dont les versions du schéma sont autorisées à évoluer. Reader
Manager
cluster
schema
Non applicable Non applicable
Les schémas sont gérés avec le code d'application qui utilise le schéma. Les nouvelles versions de schéma sont créées au moment où une application tente d'utiliser la nouvelle version de schéma. Non applicable Non applicable Reader
Writer
cluster
schema
La règle globale par défaut qui contrôle l'évolution du schéma est modifiée. Manager cluster Non applicable Non applicable

  1. Le programme d'écriture sur txnid est requis uniquement pour les produits transactionnels. ↩︎

  2. Le programme de lecture sur le groupe n'est requis que si l'affectation entraîne le consommateur à quitter son groupe en cours. ↩︎

  3. Vous n'avez pas besoin d'accéder à la ressource de schéma, mais l'accès au gestionnaire sur la ressource de cluster est requis. ↩︎

  4. Vous n'avez pas besoin d'accéder à la ressource de schéma, mais l'accès au gestionnaire sur la ressource de cluster est requis. ↩︎

  5. Lecteur si la version existe déjà, Auteur si la version doit être créée par l'appel API. ↩︎

  6. Vous n'avez pas besoin d'accéder à la ressource de schéma, mais l'accès au gestionnaire sur la ressource de cluster est requis. ↩︎