Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Configuration des prérequis pour MSK Replicator avec des clusters Apache Kafka autogérés

Création d'un rôle d'exécution IAM

Créez un rôle IAM avec une politique de confiance pourkafka.amazonaws.com. Joignez la politique AWSMSKReplicatorExecutionRole gérée. La politique gérée accorde aux clusters, aux sujets et aux groupes de consommateurs les autorisations Kafka dont le réplicateur a besoin, mais elle n'inclut AWS Secrets Manager pas les AWS KMS autorisations requises pour l'authentification et les informations d'identification. SASL/SCRAM CMK-encrypted Pour les extraits de politique en ligne à ajouter, consultez. Autorisations SER supplémentaires pour SASL/SCRAM les clés mTL et gérées par le client SASL/OAUTHBEARER

Exemple de politique de confiance :

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "kafka.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}

Configurer les autorisations des SASL/SCRAM utilisateurs et des ACL

Créez un utilisateur SCRAM dédié sur votre cluster Kafka autogéré. Les autorisations ACL suivantes sont requises :

Exemples de commandes kafka-acls.sh :

# Grant Read and Describe on all topics
kafka-acls.sh --bootstrap-server <broker>:9092 \
  --add --allow-principal User:msk-replicator \
  --operation Read --operation Describe \
  --topic '*'

# Grant Read and Describe on all consumer groups
kafka-acls.sh --bootstrap-server <broker>:9092 \
  --add --allow-principal User:msk-replicator \
  --operation Read --operation Describe \
  --group '*'

# Grant Describe on cluster
kafka-acls.sh --bootstrap-server <broker>:9092 \
  --add --allow-principal User:msk-replicator \
  --operation Describe --cluster

Configurer mTLS sur un cluster autogéré

Configurez un écouteur SSL sur vos courtiers Kafka autogérés avec. ssl.client.auth=required Le truststore du broker doit contenir le certificat CA qui a signé le certificat client que vous utiliserez pour MSK Replicator.

Accordez des autorisations ACL au principal Kafka à partir du nom distinctif (DN) du certificat client. Les autorisations requises sont les suivantes : Lire et décrire sur tous les sujets, Lire et décrire sur tous les groupes de consommateurs et Décrire sur la ressource du cluster.

Configuration SASL/OAUTHBEARER (OAuth) sur un cluster autogéré

Avec SASL/OAUTHBEARER, MSK Replicator obtient un jeton d'accès auprès de votre fournisseur d'identité (IDP) et le présente à votre cluster Kafka autogéré lors de la poignée de main (RFC 7628). SASL/OAUTHBEARER Configurez vos courtiers avec un SASL_SSL écouteur OAUTHBEARER activé et configurez la validation côté courtier des jetons émis par votre IDP. sasl.enabled.mechanisms

Accordez au principal Kafka que votre IDP mappe le jeton d'accès aux autorisations ACL requises par MSK Replicator sur le cluster source.

MSK Replicator prend en charge les mécanismes suivants pour l'acquisition d'un jeton d'accès. Vous en choisissez un lorsque vous créez le réplicateur (voirCreateReplicator Exemples d'API pour les clusters Kafka autogérés).

Les exigences suivantes s'appliquent au point de terminaison du jeton :

Configuration du protocole SSL sur un cluster autogéré

Configurez des écouteurs SSL sur vos courtiers. Pour les certificats approuvés publiquement, aucune configuration supplémentaire n'est requise. Pour les certificats privés ou auto-signés, incluez la chaîne de certificats CA complète dans le secret stocké dans AWS Secrets Manager.

Stockez les informations d'identification dans AWS Secrets Manager

Créez un secret de type Autre (non RDS/Redshift) dans AWS Secrets Manager avec les paires clé-valeur appropriées à votre type d'authentification.

Pour SASL/SCRAM :

Pour les mTL :

Pour SASL/OAUTHBEARER :

Un secret est requis pour le mécanisme d'identification du client et est facultatif pour le support JWT IAM et les mécanismes d'assertion des informations d'identification du client (ne le fournissez que si votre IDP exige que le client s'authentifie également). Le secret est un objet JSON plat composé de paires clé-valeur. MSK Replicator reconnaît les clés suivantes :

Les clés autres que l'un de ces préfixes client_id et client_secret qui n'utilisent pas l'un de ces préfixes sont ignorées. Voici un exemple de valeur secrète pour le mécanisme des informations d'identification du client :

{
  "client_id": "my-oauth-client",
  "client_secret": "example-client-secret",
  "custom_param.resource": "urn:example:kafka"
}

Configuration de la connectivité réseau

MSK Replicator nécessite une connectivité réseau à votre cluster Kafka autogéré. Options prises en charge :

Si vous l'utilisez SASL/OAUTHBEARER, le point de terminaison du jeton doit également être accessible depuis les sous-réseaux VPC que vous fournissez au réplicateur. Pour un IDP hébergé sur Internet, cela nécessite généralement une passerelle Internet, une passerelle NAT et des entrées de table de routage ; pour un IDP local ou privé, utilisez AWS Site-to-Site VPN ou Direct Connect. AWS Le point de terminaison du jeton ne doit pas être résolu en une adresse de bouclage, une adresse locale de lien ou AWS une adresse de métadonnées.

Configurer des groupes de sécurité

Assurez-vous que les groupes de sécurité autorisent le trafic entre MSK Replicator et le cluster autogéré sur le port utilisé par votre écouteur d'authentification. Mettez à jour les règles entrantes sur les groupes de sécurité VPC et les règles sortantes sur le pare-feu de cluster autogéré.