Utilisation de l'API Kafka

Kafka fournit un ensemble enrichi d'interfaces API et de clients dans un large éventail de langues. Les API incluent l'API de base, l'API Streams et l'API Connect.

  • API principale de Kafka (API Consumer, Producer et Admin) Permet d'envoyer et de recevoir des messages directement depuis une ou plusieurs rubriques Kafka. Le client d'administration Kafka fournit une interface simple via l'API Kafka pour gérer les ressources Kafka. Vous pouvez créer, supprimer et gérer des rubriques. Vous pouvez également utiliser le client d'administration pour gérer les groupes de consommateurs et leurs configurations.
  • API de flux Une API de traitement des flux de haut niveau pour consommer, transformer et produire facilement des événements entre les sujets.
  • API de connexion Un cadre qui permet des intégrations réutilisables ou standard pour diffuser des événements vers et depuis des systèmes externes, tels que des bases de données.

Le tableau suivant récapitule ce que vous pouvez utiliser avec Event Streams :

Kafka pour le support client dans les plans Standard, Enterprise et Lite.
Plan Enterprise plan Standard Plan Lite
Version Kafka sur le cluster Kafka 3.8 Kafka 3.8 Kafka 3.8
Version minimale recommandée du client Kafka Kafka 2.6.0 ou plus tard Kafka 2.6.0 ou plus tard Kafka 2.6.0 ou plus tard
Versions du client prises en charge Voir Récapitulatif du support pour tous les clients recommandés
Kafka Connect pris en charge Oui Oui Non
Kafka Streams pris en charge Oui Oui Non
ksqlDB pris en charge Oui Non Non
Conditions requises pour l'authentification Le client doit prendre en charge l'authentification à l'aide du mécanisme SASL Plain et utiliser l'extension Server Name Indication (SNI) du protocole TLSv1.2. Le client doit prendre en charge l'authentification à l'aide du mécanisme SASL Plain et utiliser l'extension Server Name Indication (SNI) du protocole TLSv1.2. Le client doit prendre en charge l'authentification à l'aide du mécanisme SASL Plain et utiliser l'extension Server Name Indication (SNI) du protocole TLSv1.2.

Choix d'un client Kafka pour une utilisation avec Event Streams

Le client officiel de l'API Kafka, qui est écrit en Java, contient les dernières fonctionnalités et les correctifs de bogue. Pour plus d'informations sur cette API, voir Kafka Producer API 3.8 et Kafka Consumer API 3.8.

Pour les autres langues, exécutez l'un des clients suivants, qui sont tous testés avec Event Streams.

Récapitulatif de la prise en charge de tous les clients recommandés

Résumé de l'assistance aux clients
Environnement Langue Version recommandée Version min. prise en charge [1] Lien vers un exemple
Client officiel Apache Kafka :
Client Apache Kafka Java 3.8.1 ou plus tard 2.5.0 Exemple de console Java

Liberty

Clients de tiers :
confluent-kafka-javascript Node.js Le plus récent 1.0.0
confluent-kafka-python Python Le plus récent 1.4.0 Exemple Kafka Python
confluent-kafka-go Go Le plus récent 1.4.0
librdkafka C ou C++ Le plus récent 1.4.0
node-rdkafka Node.js Le plus récent 2.8.0 ExempleNode.js
sarama Go Le plus récent 1.40.0 Exemples Sarama

Connexion de votre client à Event Streams

Pour savoir comment configurer votre client Java pour se connecter à Event Streams, voir Configuration de votre client.

Configuration de votre client API Kafka

Pour établir une connexion, les clients doivent être configurés pour utiliser au minimum SASL PLAIN ou SASL OAUTHBEARER sur TLSv1.2 et pour demander un nom d'utilisateur et une liste des serveurs d'amorçage. TLSv1.2 garantit que les connexions sont cryptées et valide l'authenticité des courtiers (pour éviter les attaques de type "man-in-the-middle"). SASL applique l'authentification pour toutes les connexions.

Pour récupérer le nom d'utilisateur, le mot de passe et la liste des serveurs d'amorçage, un objet d'identification de service ou une clé de service est nécessaire pour l'instance de service. Pour plus d'informations sur la création de ces objets, voir Connexion à Event Streams.

Utilisation de SASL PLAIN

Utilisez les chaînes et propriétés suivantes.

  • Utilisez la chaîne bootstrap_endpoints comme liste de serveurs d'amorçage et transmettez cette chaîne de paires hôte-port à votre client Kafka.
  • Utilisez les propriétés user et api_key comme nom d'utilisateur et mot de passe.

Pour un client Java, l'exemple suivant montre l'ensemble minimal de propriétés, où ${USERNAME}, ${PASSWORD} et ${BOOTSTRAP_ENDPOINTS} doivent être remplacés par les valeurs que vous avez récupérées précédemment.

bootstrap.servers=${BOOTSTRAP_ENDPOINTS}
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="${USERNAME}" password="${PASSWORD}";
security.protocol=SASL_SSL
ssl.protocol=TLSv1.2
ssl.enabled.protocols=TLSv1.2
ssl.endpoint.identification.algorithm=HTTPS

Si vous utilisez un client Kafka antérieur à la version 0.10.2.1, la propriété sasl.jaas.config n'est pas prise en charge et vous devez fournir la configuration du client dans un fichier de configuration JAAS.

Utilisation de SASL OAUTHBEARER avec des clients Java v3.4- 4.0

Avant de configurer le mécanisme SASL pour le client Java, il y a deux conditions préalables :

  • La version minimale du client Kafka Java prise en charge est 3.4 ( 3.6 ou une version plus récente est préférable).
  • Un paquetage jar supplémentaire doit être téléchargé depuis Maven Central et mis à disposition dans le classpath.

Si Maven est utilisé dans le système de construction, ajoutez les informations suivantes au fichier pom.xml dans la section des dépendances :

<dependency>
    <groupId>com.ibm.cloud.eventstreams</groupId>
    <artifactId>oauth-client</artifactId>
    <version>1.4.0</version>
</dependency>

Si Gradle est utilisé dans le système de construction, ajoutez les informations suivantes au fichier build.gradle dans la section des dépendances :

implementation com.ibm.cloud.eventstreams:oauth-client:1.4.0

IBM Cloud® Identity and Access Management Identity Service propose plusieurs façons de générer un jeton de porteur, dont deux sont prises en charge par cette bibliothèque client oauth :

  • clé d'API
  • Profil de confiance et jeton de ressource informatique

Utilisation de SASL OAUTHBEARER avec une clé API

Utilisez les chaînes et propriétés suivantes.

  • Utilisez la chaîne BOOTSTRAP_ENDPOINTS comme liste de serveurs d'amorçage et transmettez cette chaîne de paires hôte-port à votre client Kafka.
  • Le fichier IAMOAuthBearerLoginCallbackHandler est fourni par le package jar com.ibm.cloud.eventstreams:oauth-client:+.
  • Le point de terminaison de jeton de IBM Cloud® Identity and Access Management https://iam.cloud.ibm.com/identity/token est configuré pour générer un jeton à partir de la clé API en utilisant le type de subvention spécifié dans la configuration de jaas. La clé API n'est donc jamais envoyée au serveur, ce qui offre une meilleure sécurité qu'une clé API à longue durée de vie.
  • Le noeud final de clé Cloud Identity and Access Management https://iam.cloud.ibm.com/identity/keys est configuré pour valider le jeton.
  • grant_type à l'adresse sasl.jaas.config est urn:ibm:params:oauth:grant-type:apikey
  • apikey dans sasl.jaas.config est la clé API utilisée pour générer le jeton du porteur côté client. Il peut s'agir d'un identifiant d'utilisateur ou de service.

Pour un client Java, l'exemple suivant montre l'ensemble minimal de propriétés, où vous remplacez ${BOOTSTRAP_ENDPOINTS}, et ${APIKEY} par les valeurs que vous avez récupérées précédemment.

bootstrap.servers=${BOOTSTRAP_ENDPOINTS}
security.protocol=SASL_SSL
sasl.mechanism=OAUTHBEARER
sasl.oauthbearer.token.endpoint.url=https://iam.cloud.ibm.com/identity/token
sasl.oauthbearer.jwks.endpoint.url=https://iam.cloud.ibm.com/identity/keys
sasl.login.callback.handler.class=com.ibm.cloud.eventstreams.oauth.client.IAMOAuthBearerLoginCallbackHandler
sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required grant_type="urn:ibm:params:oauth:grant-type:apikey" apikey="${APIKEY}";

Utilisation de SASL OAUTHBEARER avec un profil de confiance et un jeton de ressource informatique

Toutes les propriétés sont les mêmes que celles décrites pour la clé API, à l'exception de sasl.jaas.config qui est différent.

  • grant_type dans sasl.jaas.config est urn:ibm:params:oauth:grant-type:cr-token.
  • profile_id dans sasl.jaas.config est l'emplacement d'un fichier stockant l'identifiant du profil de confiance. Ce fichier peut être monté sur un pod Kubernetes exécutant le code client Kafka en tant que volume en lecture seule et mis à la disposition du code client Kafka.
  • cr_token dans sasl.jaas.config est un emplacement de fichier stockant le jeton de compte de service d'un pod Kubernetes exécutant le code client Kafka. Pour plus d'informations, voir Qu'est-ce qu'un jeton de compte de service?

Exemple :

bootstrap.servers=${BOOTSTRAP_ENDPOINTS}
security.protocol=SASL_SSL
sasl.mechanism=OAUTHBEARER
sasl.oauthbearer.token.endpoint.url=https://iam.cloud.ibm.com/identity/token
sasl.oauthbearer.jwks.endpoint.url=https://iam.cloud.ibm.com/identity/keys
sasl.login.callback.handler.class=com.ibm.eventstreams.oauth.client.IAMOAuthBearerLoginCallbackHandler
sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required grant_type="urn:ibm:params:oauth:grant-type:cr-token" profile_id="${TRUSTED_PROFILE_ID_FILE_PATH}" cr_token="${SERVICE_ACCOUNT_TOKEN_FILE_PATH}";

Vous pouvez trouver plus de détails sur Comment créer un profil de confiance.

Le code source du client oauth fait référence au SDK Event Streams Java.

L'exemple de code client fait référence à l'exemple Event Streams.

Utilisation de SASL OAUTHBEARER avec les clients Java v4.1 et ultérieurs

Lors de l'utilisation d'un client Kafka Java à partir de v4.1, le client doit utiliser une version plus récente du client Event Streams oauth, qui s'appuie sur le gestionnaire de rappel par défaut de Kafka et sur un récupérateur de jetons approprié.

Si Maven est utilisé dans le système de construction, ajoutez les informations suivantes au fichier pom.xml dans la section des dépendances :

<dependency>
    <groupId>com.ibm.cloud.eventstreams</groupId>
    <artifactId>oauth-client</artifactId>
    <version>2.0.0</version>
</dependency>

Si Gradle est utilisé dans le système de construction, ajoutez les informations suivantes au fichier build.gradle dans la section des dépendances :

implementation com.ibm.cloud.eventstreams:oauth-client:2.0.+

Le service d'identité IBM Cloud® Identity and Access Management propose plusieurs façons de générer un jeton de porteur, dont deux sont prises en charge par cette bibliothèque client oauth :

  • clé d'API
  • Profil de confiance et jeton de ressource informatique

Utilisation de SASL OAUTHBEARER avec une clé API

Utilisez les chaînes et propriétés suivantes en plus de la propriété obligatoire bootstrap.servers et des paramètres spécifiques du producteur, du consommateur et de l'administrateur.

security.protocol=SASL_SSL
sasl.mechanism=OAUTHBEARER
sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
    grant_type="urn:ibm:params:oauth:grant-type:apikey" \
    apikey="${YOUR_IBM_CLOUD_API_KEY}";
sasl.login.callback.handler.class=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginCallbackHandler
sasl.oauthbearer.jwt.retriever.class=com.ibm.cloud.eventstreams.oauth.client.IAMTokenRetriever
sasl.oauthbearer.token.endpoint.url=https://private.iam.cloud.ibm.com/identity/token
sasl.oauthbearer.jwks.endpoint.url=https://private.iam.cloud.ibm.com/identity/keys

Utilisation de SASL OAUTHBEARER avec un profil de confiance et un jeton de ressource informatique dans des environnements conteneurisés

Pour plus d'informations, voir Générer un jeton IAM pour une ressource de calcul.

security.protocol=SASL_SSL
sasl.mechanism=OAUTHBEARER
sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
    grant_type="urn:ibm:params:oauth:grant-type:cr-token" \
    cr_token="/path/to/cr-token-file" \
    profile_id="/path/to/profile-id-file";
sasl.login.callback.handler.class=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginCallbackHandler
sasl.oauthbearer.jwt.retriever.class=com.ibm.cloud.eventstreams.oauth.client.IAMTokenRetriever
sasl.oauthbearer.token.endpoint.url=https://private.iam.cloud.ibm.com/identity/token
sasl.oauthbearer.jwks.endpoint.url=https://private.iam.cloud.ibm.com/identity/keys

Propriété système org.apache.kafka.sasl.oauthbearer.allowed.urls

À partir de Kafka 4.0, le client a besoin d'une propriété système pour définir les URL autorisées des points de terminaison SASL OAUTHBEARER token et jwks.

Pour plus d'informations, voir les propriétés du système.

Lors de l'utilisation des scripts shell client CLI fournis par la distribution Apache Kafka, la propriété système peut également être définie à l'aide de la variable d'environnement KAFKA_OPTS.

export KAFKA_OPTS="-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls=https://private.iam.cloud.ibm.com/identity/keys,https://private.iam.cloud.ibm.com/identity/token,https://api.metadata.cloud.ibm.com/identity/v1/iam_tokens"

Utilisation de SASL OAUTHBEARER avec des clients non Java

Pour d'autres bibliothèques client Kafka, consultez leur documentation sur l'implémentation de la prise en charge d'OAUTHBEARER. Exemple :

  • sarama: une implémentation de l'interface AccessTokenProvider est requise.
  • librdkafka: une implémentation du rappel oauthbearer_token_refresh_cb est requise.

Pour plus d'informations sur la génération d'un jeton IBM Cloud IAM à l'aide d'une clé d'API, voir IBM Cloud® Identity and Access Management document.


  1. La version la plus ancienne qui a été validée par des tests continus. Il s'agit généralement de la version initiale disponible au cours des 12 derniers mois, ou d'une version plus récente si des problèmes importants sont connus. Si vous ne pouvez pas exécuter l'un des clients répertoriés, vous pouvez utiliser d'autres clients tiers qui répondent aux exigences minimales suivantes (par exemple, librdkafka ). 1. Prend en charge Kafka 1.40ou version ultérieure. 2. Peut se connecter et s'authentifier en utilisant SASL PLAIN avec TLSv1.2. 3. Prend en charge les extensions SNI pour TLS lorsque le nom d'hôte du serveur est inclus dans la poignée de main TLS. 4. Prend en charge la cryptographie de courbe elliptique. Dans tous les cas, utilisez la dernière version du client. ↩︎