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.
# Sécurité dans Amazon MSK
La sécurité du cloud AWS est la priorité absolue. En tant que AWS client, vous bénéficiez d'un centre de données et d'une architecture réseau conçus pour répondre aux exigences des entreprises les plus sensibles en matière de sécurité.
La sécurité est une responsabilité partagée entre vous AWS et vous. Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) décrit ceci comme la sécurité *du* cloud et la sécurité *dans* le cloud :
+ **Sécurité du cloud** : AWS est chargée de protéger l'infrastructure qui exécute les AWS services dans le AWS cloud. AWS vous fournit également des services que vous pouvez utiliser en toute sécurité. Des auditeurs tiers testent et vérifient régulièrement l'efficacité de notre sécurité dans le cadre des programmes de [AWS conformité Programmes](https://aws.amazon.com/compliance/programs/) de de conformité. Pour en savoir plus sur les programmes de conformité qui s'appliquent à Amazon Managed Streaming for Apache Kafka, consultez [Services Amazon Web Services concernés par le programme de conformité](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sécurité dans le cloud** — Votre responsabilité est déterminée par le AWS service que vous utilisez. Vous êtes également responsable d’autres facteurs, y compris la sensibilité de vos données, les exigences de votre entreprise, ainsi que la législation et la réglementation applicables.
Cette documentation vous aide à comprendre comment appliquer le modèle de responsabilité partagée lors de l'utilisation d'Amazon MSK. Les rubriques suivantes vous montrent comment configurer Amazon MSK pour répondre à vos objectifs de sécurité et de conformité. Vous apprenez également à utiliser d'autres services Amazon Web Services qui vous aident à contrôler et sécuriser vos ressources Amazon MSK.
**Topics**
+ [Protection des données dans Amazon Managed Streaming for Apache Kafka](data-protection.md)
+ [Authentification et autorisation pour Amazon MSK APIs](security-iam.md)
+ [Authentification et autorisation pour Apache Kafka APIs](kafka_apis_iam.md)
+ [Modification du groupe de sécurité d'un cluster Amazon MSK](change-security-group.md)
+ [Contrôlez l'accès aux ZooKeeper nœuds Apache de votre cluster Amazon MSK](zookeeper-security.md)
+ [Validation de conformité pour Amazon Managed Streaming for Apache Kafka](MSK-compliance.md)
+ [Résilience dans Amazon Managed Streaming for Apache Kafka](disaster-recovery-resiliency.md)
+ [Sécurité de l'infrastructure dans Amazon Managed Streaming for Apache Kafka](infrastructure-security.md)
# Protection des données dans Amazon Managed Streaming for Apache Kafka
Le modèle de [responsabilité AWS partagée Le modèle](https://aws.amazon.com/compliance/shared-responsibility-model/) s'applique à la protection des données dans Amazon Managed Streaming for Apache Kafka. Comme décrit dans ce modèle, AWS est chargé de protéger l'infrastructure mondiale qui gère tous les AWS Cloud. La gestion du contrôle de votre contenu hébergé sur cette infrastructure relève de votre responsabilité. Vous êtes également responsable des tâches de configuration et de gestion de la sécurité des Services AWS que vous utilisez. Pour plus d’informations sur la confidentialité des données, consultez [Questions fréquentes (FAQ) sur la confidentialité des données](https://aws.amazon.com/compliance/data-privacy-faq/). Pour en savoir plus sur la protection des données en Europe, consultez le billet de blog [Modèle de responsabilité partagée d’AWS et RGPD (Règlement général sur la protection des données)](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) sur le *Blog de sécuritéAWS *.
À des fins de protection des données, nous vous recommandons de protéger les Compte AWS informations d'identification et de configurer les utilisateurs individuels avec AWS IAM Identity Center ou Gestion des identités et des accès AWS (IAM). Ainsi, chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour exécuter ses tâches. Nous vous recommandons également de sécuriser vos données comme indiqué ci-dessous :
+ Utilisez l’authentification multifactorielle (MFA) avec chaque compte.
+ SSL/TLS À utiliser pour communiquer avec AWS les ressources. Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Configurez l'API et la journalisation de l'activité des utilisateurs avec AWS CloudTrail. Pour plus d'informations sur l'utilisation des CloudTrail sentiers pour capturer AWS des activités, consultez la section [Utilisation des CloudTrail sentiers](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) dans le *guide de AWS CloudTrail l'utilisateur*.
+ Utilisez des solutions de AWS chiffrement, ainsi que tous les contrôles de sécurité par défaut qu'ils contiennent Services AWS.
+ Utilisez des services de sécurité gérés avancés tels qu’Amazon Macie, qui contribuent à la découverte et à la sécurisation des données sensibles stockées dans Amazon S3.
+ Si vous avez besoin de modules cryptographiques validés par la norme FIPS 140-3 pour accéder AWS via une interface de ligne de commande ou une API, utilisez un point de terminaison FIPS. Pour plus d’informations sur les points de terminaison FIPS disponibles, consultez [Norme FIPS (Federal Information Processing Standard) 140-3](https://aws.amazon.com/compliance/fips/).
Nous vous recommandons fortement de ne jamais placer d’informations confidentielles ou sensibles, telles que les adresses e-mail de vos clients, dans des balises ou des champs de texte libre tels que le champ **Nom**. Cela inclut lorsque vous travaillez avec Amazon MSK ou une autre entreprise à Services AWS l'aide de la console, de l'API ou AWS SDKs. AWS CLI Toutes les données que vous entrez dans des balises ou des champs de texte de forme libre utilisés pour les noms peuvent être utilisées à des fins de facturation ou dans les journaux de diagnostic. Si vous fournissez une adresse URL à un serveur externe, nous vous recommandons fortement de ne pas inclure d’informations d’identification dans l’adresse URL permettant de valider votre demande adressée à ce serveur.
**Topics**
+ [Chiffrement Amazon MSK](msk-encryption.md)
+ [Commencez avec le chiffrement Amazon MSK](msk-working-with-encryption.md)
+ [Utiliser Amazon MSK APIs avec des points de terminaison VPC d'interface](privatelink-vpc-endpoints.md)
# Chiffrement Amazon MSK
Amazon MSK fournit des options de chiffrement des données que vous pouvez utiliser pour répondre à des exigences strictes en matière de gestion des données. Les certificats utilisés par Amazon MSK pour le chiffrement doivent être renouvelés tous les 13 mois. Amazon MSK renouvelle automatiquement ces certificats pour tous les clusters. Les clusters Express Broker restent en `ACTIVE` état lorsqu'Amazon MSK lance l'opération de mise à jour des certificats. Pour les clusters de courtiers standard, Amazon MSK définit l'état du cluster au `MAINTENANCE` moment où il commence l'opération de mise à jour des certificats. MSK le rétablit à la fin `ACTIVE` de la mise à jour. Lorsqu'un cluster est en cours d'opération de mise à jour des certificats, vous pouvez continuer à produire et à consommer des données, mais vous ne pouvez effectuer aucune opération de mise à jour sur celui-ci.
## Chiffrement Amazon MSK au repos
Amazon MSK s'intègre à [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/) (KMS) pour permettre le chiffrement transparent côté serveur. Amazon MSK chiffre toujours vos données au repos. Lorsque vous créez un cluster MSK, vous pouvez spécifier la AWS KMS key que vous souhaitez qu'Amazon MSK utilise pour chiffrer vos données au repos. Si vous ne spécifiez pas de clé KMS, Amazon MSK crée une [Clé gérée par AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) pour vous et l'utilise en votre nom. Pour plus d'informations sur les clés KMS, consultez [AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) dans le *Guide du développeur AWS Key Management Service *.
## Chiffrement Amazon MSK en transit
Amazon MSK utilise TLS 1.2. Par défaut, il chiffre les données en transit entre les agents de votre cluster MSK. Vous pouvez remplacer cette valeur par défaut au moment de la création du cluster.
Pour la communication entre clients et brokers, vous devez spécifier l'un des trois paramètres suivants :
+ Autoriser uniquement les données chiffrées TLS. Il s’agit du paramètre par défaut.
+ Autoriser à la fois le texte brut, ainsi que les données chiffrées TLS.
+ Autoriser uniquement les données en texte brut.
Les courtiers Amazon MSK utilisent des AWS Certificate Manager certificats publics. Par conséquent, tout magasin fiable qui fait confiance à Amazon Trust Services approuve également les certificats des agents Amazon MSK.
Bien que nous vous recommandions d'activer le chiffrement en transit, celui-ci peut entraîner des charges supplémentaires d'UC et quelques millisecondes de latence. La plupart des cas d'utilisation ne sont toutefois pas sensibles à ces différences, cependant l'ampleur de l'impact dépend de la configuration du cluster, des clients et du profil d'utilisation.
# Commencez avec le chiffrement Amazon MSK
Lors de la création d'un cluster MSK, vous pouvez spécifier les paramètres de chiffrement au format JSON. Voici un exemple.
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:123456789012:key/abcdabcd-1234-abcd-1234-abcd123e8e8e"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
Pour `DataVolumeKMSKeyId`, vous pouvez spécifier une [clé gérée par le client](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) ou la Clé gérée par AWS pour MSK dans votre compte (`alias/aws/kafka`). Si vous ne le spécifiez pas`EncryptionAtRest`, Amazon MSK chiffre toujours vos données au repos sous le. Clé gérée par AWS Pour déterminer la clé utilisée par votre cluster, envoyez une requête `GET` ou invoquez l'opération d'API `DescribeCluster`.
Pour `EncryptionInTransit`, la valeur par défaut de `InCluster` est true, mais vous pouvez la définir sur false si vous ne voulez pas qu'Amazon MSK chiffre vos données au fur et à mesure qu'elles passent entre les agents.
Pour spécifier le mode de chiffrement des données en transit entre les clients et les brokers, définissez `ClientBroker` sur l'une des trois valeurs suivantes : `TLS`, `TLS_PLAINTEXT` ou `PLAINTEXT`.
**Topics**
+ [Spécifiez les paramètres de chiffrement lors de la création d'un cluster Amazon MSK](msk-working-with-encryption-cluster-create.md)
+ [Testez le chiffrement Amazon MSK TLS](msk-working-with-encryption-test-tls.md)
# Spécifiez les paramètres de chiffrement lors de la création d'un cluster Amazon MSK
Ce processus décrit comment spécifier les paramètres de chiffrement lors de la création d'un cluster Amazon MSK.
**Spécifier les paramètres de chiffrement lors de la création d'un cluster**
1. Enregistrez le contenu de l'exemple précédent dans un fichier et donnez au fichier le nom souhaité. Par exemple, appelez-le `encryption-settings.json`.
1. Exécutez la commande `create-cluster` et utilisez l'option `encryption-info` pour pointer vers le fichier dans lequel vous avez enregistré votre JSON de configuration. Voici un exemple. *\$1YOUR MSK VERSION\$1*Remplacez-le par une version qui correspond à la version du client Apache Kafka. Pour de plus amples informations sur la recherche de la version de votre cluster MSK, consultez [Déterminer la version de votre cluster MSK](create-topic.md#find-msk-cluster-version). Sachez que l'utilisation d'une version du client Apache Kafka différente de la version de votre cluster MSK peut entraîner la corruption, la perte et l'arrêt des données d'Apache Kafka.
```
aws kafka create-cluster --cluster-name "ExampleClusterName" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --kafka-version "{YOUR MSK VERSION}" --number-of-broker-nodes 3
```
Voici un exemple de réponse réussie après l'exécution de cette commande.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:123456789012:cluster/SecondTLSTest/abcdabcd-1234-abcd-1234-abcd123e8e8e",
"ClusterName": "ExampleClusterName",
"State": "CREATING"
}
```
# Testez le chiffrement Amazon MSK TLS
Ce processus décrit comment tester le chiffrement TLS sur Amazon MSK.
**Pour tester le chiffrement TLS**
1. Créez une machine client en suivant les instructions de [Étape 3 : Créer un ordinateur client](create-client-machine.md).
1. Installez Apache Kafka sur l'ordinateur client.
1. Dans cet exemple, nous utilisons le magasin fiable JVM pour parler au cluster MSK. Pour ce faire, créez d'abord un dossier nommé `/tmp` sur l'ordinateur client. Ensuite, accédez au dossier `bin` de l'installation d'Apache Kafka et exécutez la commande suivante. (Votre chemin JVM peut être différent.)
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. Dans le dossier `bin` de l'installation d'Apache Kafka sur l'ordinateur client, créez un fichier texte nommé `client.properties` avec le contenu suivant.
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka.client.truststore.jks
```
1. Exécutez la commande suivante sur une machine sur laquelle le est AWS CLI installé, en le *clusterARN* remplaçant par l'ARN de votre cluster.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
Un résultat réussi ressemble à ce qui suit. Enregistrez ce résultat car vous en avez besoin pour l'étape suivante.
```
{
"BootstrapBrokerStringTls": "a-1.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-3.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-2.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123"
}
```
1. Exécutez la commande suivante, en la *BootstrapBrokerStringTls* remplaçant par l'un des points de terminaison du broker que vous avez obtenus à l'étape précédente.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringTls --producer.config client.properties --topic TLSTestTopic
```
1. Ouvrez une nouvelle fenêtre de commande et connectez-vous au même ordinateur client. Exécutez ensuite la commande suivante pour créer un consommateur de console.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringTls --consumer.config client.properties --topic TLSTestTopic
```
1. Dans la fenêtre du producteur, tapez un message texte suivi d'un retour et recherchez le même message dans la fenêtre du consommateur. Amazon MSK a chiffré ce message en transit.
Pour de plus amples informations sur la configuration des clients Apache Kafka pour qu'ils fonctionnent avec des données chiffrées, veuillez consulter [Configuration des clients Kafka](https://kafka.apache.org/documentation/#security_configclients).
# Utiliser Amazon MSK APIs avec des points de terminaison VPC d'interface
Vous pouvez utiliser un point de terminaison VPC d'interface, alimenté par AWS PrivateLink, pour empêcher le trafic entre votre Amazon VPC et Amazon APIs MSK de quitter le réseau Amazon. Les points de terminaison VPC d'interface ne nécessitent pas de passerelle Internet, de périphérique NAT, de connexion VPN ou de connexion Direct AWS Connect. [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)est une AWS technologie qui permet une communication privée entre les AWS services à l'aide d'une interface réseau élastique avec private IPs dans votre Amazon VPC. Pour plus d'informations, consultez [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) and [Interface VPC Endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint) ().AWS PrivateLink
Vos applications peuvent se connecter à Amazon MSK Provisioned et MSK Connect APIs à l'aide de. AWS PrivateLink Pour commencer, créez un point de terminaison VPC d'interface pour votre API Amazon MSK afin de démarrer le trafic en provenance et à destination de vos ressources Amazon VPC via le point de terminaison VPC d'interface. Les points de terminaison VPC d'interface compatibles FIPS sont disponibles pour les régions des États-Unis. Pour plus d'informations, consultez la section [Créer un point de terminaison d'interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint).
Grâce à cette fonctionnalité, vos clients Apache Kafka peuvent récupérer dynamiquement les chaînes de connexion pour se connecter aux ressources MSK Provisioned ou MSK Connect sans passer par Internet pour récupérer les chaînes de connexion.
Lors de la création d'un point de terminaison VPC d'interface, choisissez l'un des points de terminaison de nom de service suivants :
**Pour MSK Provisioned :**
+ Les points de terminaison de nom de service suivants ne sont plus pris en charge pour les nouvelles connexions :
+ com.amazonaws.region.kafka
+ com.amazonaws.region.kafka-fips (compatible FIPS)
+ Le service de point de terminaison Dualstack prenant en charge les deux IPv4 et le IPv6 trafic est le suivant :
+ aws.api.region.kafka-api
+ aws.api.region. kafka-api-fips (compatible FIPS)
Pour configurer les points de terminaison à double pile, vous devez suivre les directives relatives aux points de terminaison [à double pile et FIPS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html).
Où est le nom de votre région. Choisissez ce nom de service pour fonctionner avec MSK Provisioned APIs compatible. Pour plus d'informations, consultez la section [Operations in the https://docs.aws.amazon.com/msk/](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html) *1.0/apireference/*.
**Pour MSK Connect :**
+ com.amazonaws.region.kafkaconnect
Où est le nom de votre région. Choisissez ce nom de service pour fonctionner avec MSK Connect APIs compatible. Pour plus d'informations, consultez [Actions](https://docs.aws.amazon.com/MSKC/latest/mskc/API_Operations.html) dans le manuel *Amazon MSK Connect API Reference*.
*Pour plus d'informations, y compris step-by-step les instructions pour créer un point de terminaison VPC d'interface, consultez la section [Création d'un point de terminaison d'interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint) dans le AWS PrivateLink Guide.*
## Contrôlez l'accès aux points de terminaison VPC pour Amazon MSK Provisioned ou MSK Connect APIs
Les politiques de point de terminaison VPC vous permettent de contrôler l'accès en attachant une politique à un point de terminaison VPC ou en utilisant des champs supplémentaires dans une politique attachée à un utilisateur, un groupe ou un rôle IAM afin de limiter l'accès uniquement via le point de terminaison VPC spécifié. Utilisez l'exemple de politique approprié pour définir les autorisations d'accès pour le service MSK Provisioned ou MSK Connect.
Si vous n’attachez pas de stratégie quand vous créez un point de terminaison, Amazon VPC attache une stratégie par défaut pour vous qui autorise un accès total au service. Une politique de point de terminaison n’annule pas et ne remplace pas les politiques IAM ou les politiques spécifiques aux services. Il s’agit d’une politique distincte qui contrôle l’accès depuis le point de terminaison jusqu’au service spécifié.
*Pour plus d'informations, consultez la section [Contrôle de l'accès aux services avec des points de terminaison VPC dans le guide](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html).AWS PrivateLink *
------
#### [ MSK Provisioned — VPC policy example ]
**Accès en lecture seule**
Cet exemple de politique peut être attaché à un point de terminaison VPC. (Pour de plus amples informations, veuillez consulter Contrôle de l'accès aux ressources VPC Amazon). Il limite les actions à la seule liste et à la description des opérations via le point de terminaison VPC auquel il est attaché.
```
{
"Statement": [
{
"Sid": "MSKReadOnly",
"Principal": "*",
"Action": [
"kafka:List*",
"kafka:Describe*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
**MSK Provisioned — Exemple de politique de point de terminaison VPC**
Restreindre l'accès à un cluster MSK spécifique
Cet exemple de politique peut être attaché à un point de terminaison VPC. Il restreint l'accès à un cluster Kafka spécifique via le point de terminaison VPC auquel il est attaché.
```
{
"Statement": [
{
"Sid": "AccessToSpecificCluster",
"Principal": "*",
"Action": "kafka:*",
"Effect": "Allow",
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster"
}
]
}
```
------
#### [ MSK Connect — VPC endpoint policy example ]
**Répertorier les connecteurs et créer un nouveau connecteur**
Voici un exemple de politique de point de terminaison pour MSK Connect. Cette politique permet au rôle spécifié de répertorier les connecteurs et de créer un nouveau connecteur.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "MSKConnectPermissions",
"Effect": "Allow",
"Action": [
"kafkaconnect:ListConnectors",
"kafkaconnect:CreateConnector"
],
"Resource": "*",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/MyMSKConnectExecutionRole"
]
}
}
]
}
```
**MSK Connect — Exemple de politique de point de terminaison VPC**
Autorise uniquement les demandes provenant d'une adresse IP spécifique dans le VPC spécifié
L’exemple suivant montre une politique qui autorise uniquement les demandes provenant d’une adresse IP spécifiée dans le VPC spécifié. Les demandes provenant d’autres adresses IP échoueront.
```
{
"Statement": [
{
"Action": "kafkaconnect:*",
"Effect": "Allow",
"Principal": "*",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:VpcSourceIp": "192.0.2.123"
},
"StringEquals": {
"aws:SourceVpc": "vpc-555555555555"
}
}
}
]
}
```
------
# Authentification et autorisation pour Amazon MSK APIs
Gestion des identités et des accès AWS (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Des administrateurs IAM contrôlent les personnes qui peuvent être *authentifiées* (connectées) et *autorisées* (disposant d'autorisations) à utiliser des ressources Amazon MSK. IAM est un Service AWS outil que vous pouvez utiliser sans frais supplémentaires.
**Topics**
+ [Fonctionnement d'Amazon MSK avec IAM](security_iam_service-with-iam.md)
+ [Exemples de politiques basées sur l'identité d'Amazon MSK](security_iam_id-based-policy-examples.md)
+ [Rôles liés à un service pour Amazon MSK](using-service-linked-roles.md)
+ [AWS politiques gérées pour Amazon MSK](security-iam-awsmanpol.md)
+ [Résoudre les problèmes liés à l'identité et à l'accès à Amazon MSK](security_iam_troubleshoot.md)
# Fonctionnement d'Amazon MSK avec IAM
Avant d'utiliser IAM pour gérer l'accès à Amazon MSK, vous devez comprendre quelles sont les fonctionnalités IAM pouvant être utilisées dans cette situation. Pour obtenir une vue d'ensemble de la manière dont Amazon MSK et les autres AWS services fonctionnent avec IAM, consultez la section [AWS Services That Work with IAM dans le guide de l'utilisateur *IAM*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).
**Topics**
+ [Politiques basées sur l'identité Amazon MSK](security_iam_service-with-iam-id-based-policies.md)
+ [Politiques basées sur des ressources Amazon MSK](security_iam_service-with-iam-resource-based-policies.md)
+ [Autorisation basée sur les balises Amazon MSK](security_iam_service-with-iam-tags.md)
+ [Rôles IAM Amazon MSK](security_iam_service-with-iam-roles.md)
# Politiques basées sur l'identité Amazon MSK
Avec les politiques IAM basées sur l’identité, vous pouvez spécifier des actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Amazon MSK prend en charge des actions, des ressources et des clés de condition spécifiques. Pour en savoir plus sur tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l’utilisateur IAM*.
## Actions pour les politiques basées sur l'identité d'Amazon MSK
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Action` d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Intégration d’actions dans une politique afin d’accorder l’autorisation d’exécuter les opérations associées.
Les actions de politique dans Amazon MSK utilisent le préfixe suivant avant l'action : `kafka:`. Par exemple, pour accorder à une personne l'autorisation de décrire un cluster MSK avec l'opération d'API Amazon MSK `DescribeCluster`, vous incluez l'action `kafka:DescribeCluster` dans sa politique. Les déclarations de politique doivent inclure un élément `Action` ou `NotAction`. Amazon MSK définit son propre ensemble d'actions qui décrivent les tâches que vous pouvez effectuer avec ce service.
Veuillez noter que les actions politiques pour le sujet MSK APIs utilisent le `kafka-cluster` préfixe situé avant l'action, reportez-vous au. [Sémantique des politiques d'autorisation, des actions et des ressources de l'IAM](kafka-actions.md)
Pour spécifier plusieurs actions dans une seule déclaration, séparez-les par des virgules comme suit :
```
"Action": ["kafka:action1", "kafka:action2"]
```
Vous pouvez aussi spécifier plusieurs actions à l’aide de caractères génériques (\$1). Par exemple, pour spécifier toutes les actions qui commencent par le mot `Describe`, incluez l’action suivante :
```
"Action": "kafka:Describe*"
```
Pour afficher la liste des actions Amazon MSK, consultez [Actions, ressources et clés de condition pour Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonmanagedstreamingforapachekafka.html) dans le *Guide de l'utilisateur IAM*.
## Ressources pour les politiques basées sur l'identité d'Amazon MSK
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément de politique JSON `Resource` indique le ou les objets auxquels l’action s’applique. Il est recommandé de définir une ressource à l’aide de son [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (\$1) afin d’indiquer que l’instruction s’applique à toutes les ressources.
```
"Resource": "*"
```
La ressource d'instance Amazon MSK possède l'ARN suivant :
```
arn:${Partition}:kafka:${Region}:${Account}:cluster/${ClusterName}/${UUID}
```
Pour plus d'informations sur le format de ARNs, consultez [Amazon Resource Names (ARNs) et AWS Service Namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
Par exemple, pour spécifier l’instance `CustomerMessages` dans votre instruction, utilisez l’ARN suivant :
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/CustomerMessages/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2"
```
Pour spécifier toutes les instances qui appartiennent à un compte spécifique, utilisez le caractère générique (\$1) :
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*"
```
Certaines actions Amazon MSK, telles que celles destinées à la création de ressources, ne peuvent pas être exécutées sur une ressource spécifique. Dans ces cas-là, vous devez utiliser le caractère générique (\$1).
```
"Resource": "*"
```
Pour spécifier plusieurs ressources dans une seule instruction, séparez-les ARNs par des virgules.
```
"Resource": ["resource1", "resource2"]
```
Pour consulter la liste des types de ressources Amazon MSK et leurs caractéristiques ARNs, consultez la section [Resources Defined by Amazon Managed Streaming for Apache](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-resources-for-iam-policies) Kafka Kafka dans *le guide de l'utilisateur IAM*. Pour savoir les actions avec lesquelles vous pouvez spécifier l'ARN de chaque ressource, consultez [Actions définies par Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions).
## Clés de condition pour les politiques basées sur l'identité d'Amazon MSK
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Condition` indique à quel moment les instructions s’exécutent en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des [opérateurs de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tels que les signes égal ou inférieur à, pour faire correspondre la condition de la politique aux valeurs de la demande. Pour voir toutes les clés de condition AWS globales, voir les clés de [contexte de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.
Amazon MSK définit son propre ensemble de clés de condition et est également compatible avec l'utilisation de certaines clés de condition globales. Pour voir toutes les clés de condition AWS globales, consultez la section [Clés contextuelles de condition AWS globale](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.
Pour afficher une liste des clés de condition Amazon MSK, consultez [Clés de condition pour Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-policy-keys) dans le *Guide de l'utilisateur IAM*. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez [Actions définies par Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions).
## Exemples de politiques basées sur l'identité Amazon MSK
Pour voir des exemples de politiques Amazon MSK basées sur l'identité, consultez [Exemples de politiques basées sur l'identité d'Amazon MSK](security_iam_id-based-policy-examples.md).
# Politiques basées sur des ressources Amazon MSK
Amazon MSK prend en charge une politique de cluster (également appelée politique basée sur des ressources) à utiliser avec les clusters Amazon MSK. Vous pouvez utiliser une politique de cluster pour définir quels principaux IAM disposent d'autorisations intercompte pour configurer une connectivité privée avec votre cluster Amazon MSK. Lorsqu'elle est utilisée avec l'authentification du client IAM, vous pouvez également utiliser la politique de cluster pour définir de manière granulaire les autorisations de plan de données Kafka pour les clients qui se connectent.
La taille maximale prise en charge pour une politique de cluster est de 20 Ko.
Pour voir un exemple de configuration d'une politique de cluster, reportez-vous à [Étape 2 : attacher une politique de cluster au cluster MSK](mvpc-cluster-owner-action-policy.md).
# Autorisation basée sur les balises Amazon MSK
Vous pouvez attacher des balises aux clusters Amazon MSK. Pour contrôler l’accès basé sur des étiquettes, vous devez fournir les informations d’étiquette dans l’[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une politique utilisant les clés de condition `kafka:ResourceTag/key-name`, `aws:RequestTag/key-name` ou `aws:TagKeys`. Pour plus d'informations sur le balisage des ressources Amazon MSK, consultez. [Marquer un cluster Amazon MSK](msk-tagging.md)
Vous ne pouvez contrôler l'accès au cluster qu'à l'aide de balises. Pour étiqueter des sujets et des groupes de consommateurs, vous devez ajouter une déclaration distincte dans vos politiques sans balises.
Pour voir un exemple de politique basée sur l'identité visant à limiter l'accès à un cluster en fonction des balises de ce cluster, consultez. [Accès aux clusters Amazon MSK à l'aide de balises](security_iam_id-based-policy-examples-view-widget-tags.md)
Vous pouvez utiliser des conditions dans votre politique basée sur l'identité pour contrôler l'accès aux ressources Amazon MSK en fonction des balises. L'exemple suivant montre une politique qui permet à un utilisateur de décrire le cluster, d'obtenir ses courtiers bootstrap, de répertorier ses nœuds de courtiers, de le mettre à jour et de le supprimer. Toutefois, cette politique n'accorde l'autorisation que si la balise de cluster `Owner` a la valeur de celle de cet utilisateur`username`. La deuxième déclaration de la politique suivante autorise l'accès aux rubriques du cluster. La première déclaration de cette politique n'autorise aucun accès aux rubriques.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/*"
]
}
]
}
```
------
# Rôles IAM Amazon MSK
Un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) est une entité au sein de votre compte Amazon Web Services qui dispose d'autorisations spécifiques.
## Utilisation d'informations d'identification temporaires avec Amazon MSK
Vous pouvez utiliser des informations d'identification temporaires pour vous connecter à l'aide de la fédération, endosser un rôle IAM ou encore pour endosser un rôle intercompte. Vous obtenez des informations d'identification de sécurité temporaires en appelant des opérations d' AWS STS API telles que [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)ou [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html).
Amazon MSK prend en charge l'utilisation d'informations d'identification temporaires.
## Rôles liés à un service
Les [rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) permettent aux services Amazon Web Services d'accéder à des ressources dans d'autres services pour effectuer une action en votre nom. Les rôles liés à un service s'affichent dans votre compte IAM et sont la propriété du service. Un administrateur peut consulter, mais ne peut pas modifier les autorisations concernant les rôles liés à un service.
Amazon MSK prend en charge les rôles liés à un service. Pour plus d'informations sur la création ou la gestion de rôles liés à un service dans Amazon MSK, consultez [Rôles liés à un service pour Amazon MSK](using-service-linked-roles.md).
# Exemples de politiques basées sur l'identité d'Amazon MSK
Par défaut, les utilisateurs et les rôles IAM ne sont pas autorisés à effectuer des actions d'API Amazon MSK. Un administrateur doit créer des politiques IAM autorisant les utilisateurs et les rôles à exécuter des opérations d’API spécifiques sur les ressources spécifiées dont ils ont besoin. Il doit ensuite attacher ces politiques aux utilisateurs ou aux groupes IAM ayant besoin de ces autorisations.
Pour savoir comment créer une stratégie IAM basée sur l'identité à l'aide de ces exemples de documents de stratégie JSON, veuillez consulter [Création de stratégies dans l'onglet JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) dans le *Guide de l'utilisateur IAM*.
**Topics**
+ [Bonnes pratiques en matière de politiques](security_iam_service-with-iam-policy-best-practices.md)
+ [Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Accès à un cluster Amazon MSK](security_iam_id-based-policy-examples-access-one-cluster.md)
+ [Accès aux clusters Amazon MSK à l'aide de balises](security_iam_id-based-policy-examples-view-widget-tags.md)
# Bonnes pratiques en matière de politiques
Les politiques basées sur l'identité déterminent si une personne peut créer, consulter ou supprimer des ressources Amazon MSK dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
+ **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*.
+ **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*.
Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*.
# Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations
Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or AWS .
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Accès à un cluster Amazon MSK
Dans cet exemple, vous souhaitez accorder à un utilisateur IAM de votre compte Amazon Web Services l'accès à l'un de vos clusters, `purchaseQueriesCluster`. Cette stratégie permet à l'utilisateur de décrire le cluster, d'obtenir ses brokers d'amorçage, de répertorier ses nœuds de broker et de le mettre à jour.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"UpdateCluster",
"Effect":"Allow",
"Action":[
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*"
],
"Resource":"arn:aws:kafka:us-east-1:012345678012:cluster/purchaseQueriesCluster/abcdefab-1234-abcd-5678-cdef0123ab01-2"
}
]
}
```
------
# Accès aux clusters Amazon MSK à l'aide de balises
Vous pouvez utiliser des conditions dans votre politique basée sur l'identité pour contrôler l'accès aux ressources Amazon MSK en fonction des balises. Cet exemple montre comment créer une stratégie qui permet à l'utilisateur de décrire le cluster, d'obtenir ses brokers d'amorçage, de répertorier ses nœuds de broker, de le mettre à jour et de le supprimer. Toutefois, l'autorisation est accordée uniquement si la balise de cluster `Owner` a la valeur du nom d'utilisateur de cet utilisateur.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:012345678012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
}
]
}
```
------
Vous pouvez rattacher cette politique aux utilisateurs IAM de votre compte. Si un utilisateur nommé `richard-roe` tente de mettre à jour un cluster MSK, le cluster doit être balisé `Owner=richard-roe` ou `owner=richard-roe`. Dans le cas contraire, l’utilisateur se voit refuser l'accès. La clé de condition d'étiquette `Owner` correspond à la fois à `Owner` et à `owner`, car les noms de clé de condition ne sont pas sensibles à la casse. Pour plus d'informations, veuillez consulter la rubrique [Éléments de stratégie JSON IAM : Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l'utilisateur IAM*.
# Rôles liés à un service pour Amazon MSK
Amazon MSK utilise des rôles liés à un [service Gestion des identités et des accès AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Un rôle lié à un service est un type unique de rôle IAM qui est lié directement à Amazon MSK. Les rôles liés à un service sont prédéfinis par Amazon MSK et incluent toutes les autorisations requises par le service pour appeler d'autres AWS services en votre nom.
Un rôle lié à un service simplifie la configuration d'Amazon MSK, car vous n'avez pas besoin d'ajouter manuellement les autorisations requises. Amazon MSK définit les autorisations de ses rôles liés à un service. Sauf indication contraire, seul Amazon MSK peut assumer ses rôles. Les autorisations définies comprennent la politique de confiance et la politique d’autorisation. De plus, cette politique d’autorisation ne peut pas être attachée à une autre entité IAM.
Pour plus d'informations sur les autres services qui prennent en charge les rôles liés à un service, consultez [Services Amazon Web Services qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et recherchez les services où **Oui** figure dans la colonne **Rôle lié à un service**. Choisissez un **Oui** ayant un lien permettant de consulter les détails du rôle pour ce service.
**Topics**
+ [Autorisations de rôles liés à un service](slr-permissions.md)
+ [Créer un rôle lié à un service](create-slr.md)
+ [Modification d’un rôle lié à un service](edit-slr.md)
+ [Régions prises en charge pour les rôles liés à un service](slr-regions.md)
# Autorisations du rôle lié à un service pour Amazon MSK
Amazon MSK utilise le rôle lié à un service nommé **AWSServiceRoleForKafka**. Amazon MSK utilise ce rôle pour accéder à vos ressources et effectuer des opérations telles que :
+ `*NetworkInterface` - créer et gérer des interfaces réseau dans le compte client qui rendent les agents de cluster accessibles aux clients dans le VPC du client.
+ `*VpcEndpoints`— gérez les points de terminaison VPC dans le compte client afin de rendre les courtiers de clusters accessibles aux clients utilisant le VPC du client. AWS PrivateLink Amazon MSK utilise des autorisations pour `DescribeVpcEndpoints`, `ModifyVpcEndpoint` et `DeleteVpcEndpoints`.
+ `secretsmanager`— gérez les informations d'identification des clients avec AWS Secrets Manager.
+ `GetCertificateAuthorityCertificate` - récupérer le certificat pour votre autorité de certification privée.
+ `*Ipv6Addresses`— attribuer et annuler l'attribution d' IPv6 adresses aux interfaces réseau du compte client afin de permettre la IPv6 connectivité des clusters MSK.
+ `ModifyNetworkInterfaceAttribute`— modifiez les attributs de l'interface réseau dans le compte client pour configurer IPv6 les paramètres de connectivité au cluster MSK.
Ce rôle lié à un service est attaché à la politique gérée suivante : `KafkaServiceRolePolicy`. Pour connaître les mises à jour de cette politique, consultez [KafkaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/KafkaServiceRolePolicy.html).
Le rôle lié à un service AWSServiceRoleForKafka approuve les services suivants pour endosser le rôle :
+ `kafka.amazonaws.com`
La politique d'autorisations liée au rôle permet à Amazon MSK de réaliser les actions suivantes au niveau des ressources.
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Pour en savoir plus, consultez [Service-Linked Role Permissions (autorisations du rôle lié à un service)](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l’utilisateur IAM*.
# Création d'un rôle lié à un service pour Amazon MSK
Vous n'avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous créez un cluster Amazon MSK dans l' AWS Management Console AWS API AWS CLI, Amazon MSK crée le rôle lié au service pour vous.
Si vous supprimez ce rôle lié à un service et que vous avez ensuite besoin de le recréer, vous pouvez utiliser la même procédure pour recréer le rôle dans votre compte. Lorsque vous créez un cluster Amazon MSK, Amazon MSK crée à nouveau automatiquement le rôle lié au service.
# Modifier un rôle lié à un service pour Amazon MSK
Amazon MSK ne vous autorise pas à modifier le rôle lié à un service AWSServiceRoleForKafka. Après avoir créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence à ce rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM. Pour en savoir plus, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *Guide de l’utilisateur IAM*.
# Régions prises en charge pour les rôles liés à un service Amazon MSK
Amazon MSK prend en charge l'utilisation des rôles liés à un service dans toutes les régions où le service est disponible. Pour plus d’informations, consultez [AWS Régions et points de terminaison](https://docs.aws.amazon.com/general/latest/gr/rande.html).
# AWS politiques gérées pour Amazon MSK
Une politique AWS gérée est une politique autonome créée et administrée par AWS. AWS les politiques gérées sont conçues pour fournir des autorisations pour de nombreux cas d'utilisation courants afin que vous puissiez commencer à attribuer des autorisations aux utilisateurs, aux groupes et aux rôles.
N'oubliez pas que les politiques AWS gérées peuvent ne pas accorder d'autorisations de moindre privilège pour vos cas d'utilisation spécifiques, car elles sont accessibles à tous les AWS clients. Nous vous recommandons de réduire encore les autorisations en définissant des [politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) qui sont propres à vos cas d’utilisation.
Vous ne pouvez pas modifier les autorisations définies dans les politiques AWS gérées. Si les autorisations définies dans une politique AWS gérée sont AWS mises à jour, la mise à jour affecte toutes les identités principales (utilisateurs, groupes et rôles) auxquelles la politique est attachée. AWS est le plus susceptible de mettre à jour une politique AWS gérée lorsqu'une nouvelle Service AWS est lancée ou lorsque de nouvelles opérations d'API sont disponibles pour les services existants.
Pour plus d’informations, consultez [Politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *Guide de l’utilisateur IAM*.
# AWS politique gérée : Amazon MSKFull Access
Cette politique accorde des autorisations administratives qui permettent à un principal d'accéder pleinement à toutes les actions Amazon MSK. Les autorisations définies dans cette politique sont regroupées comme suit :
+ Les autorisations Amazon MSK autorisent toutes les actions Amazon MSK.
+ **`Amazon EC2`autorisations** : dans cette politique, elles sont requises pour valider les ressources transmises dans une demande d'API. Cela permet de s'assurer qu'Amazon MSK est en mesure d'utiliser correctement les ressources avec un cluster. Les autres autorisations Amazon EC2 de cette politique permettent à Amazon MSK de créer les AWS ressources nécessaires pour vous permettre de vous connecter à vos clusters.
+ **`AWS KMS`autorisations** — sont utilisées lors des appels d'API pour valider les ressources transmises dans une demande. Elles sont nécessaires pour qu'Amazon MSK puisse utiliser la clé transmise avec le cluster Amazon MSK.
+ **`CloudWatch Logs, Amazon S3, and Amazon Data Firehose`autorisations** : elles sont nécessaires pour qu'Amazon MSK puisse garantir que les destinations de livraison des journaux sont accessibles et qu'elles sont valides pour l'utilisation des journaux des courtiers.
+ **`IAM`autorisations** : elles sont nécessaires pour qu'Amazon MSK puisse créer un rôle lié à un service dans votre compte et pour vous permettre de transmettre un rôle d'exécution de service à Amazon MSK.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"kafka:*",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeSecurityGroups",
"ec2:DescribeRouteTables",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcAttribute",
"kms:DescribeKey",
"kms:CreateGrant",
"logs:CreateLogDelivery",
"logs:GetLogDelivery",
"logs:UpdateLogDelivery",
"logs:DeleteLogDelivery",
"logs:ListLogDeliveries",
"logs:PutResourcePolicy",
"logs:DescribeResourcePolicies",
"logs:DescribeLogGroups",
"S3:GetBucketPolicy",
"firehose:TagDeliveryStream"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc/*",
"arn:*:ec2:*:*:subnet/*",
"arn:*:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc-endpoint/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/AWSMSKManaged": "true"
},
"StringLike": {
"aws:RequestTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateVpcEndpoint"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteVpcEndpoints"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AWSMSKManaged": "true"
},
"StringLike": {
"ec2:ResourceTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/delivery.logs.amazonaws.com/AWSServiceRoleForLogDelivery*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "delivery.logs.amazonaws.com"
}
}
}
]
}
```
------
# AWS politique gérée : Amazon MSKRead OnlyAccess
Cette politique accorde des autorisations en lecture seule qui permettent aux utilisateurs de consulter des informations dans Amazon MSK. Les principaux auxquels cette politique est attachée ne peuvent effectuer aucune mise à jour ou supprimer des ressources existantes, ni créer de nouvelles ressources Amazon MSK. Par exemple, les principaux disposant de ces autorisations peuvent consulter la liste des clusters et des configurations associés à leur compte, mais ne peuvent pas modifier la configuration ou les paramètres des clusters. Les autorisations définies dans cette politique sont regroupées comme suit :
+ **`Amazon MSK`autorisations** : vous permettent de répertorier les ressources Amazon MSK, de les décrire et d'obtenir des informations à leur sujet.
+ **`Amazon EC2`autorisations** : elles sont utilisées pour décrire le VPC Amazon, les sous-réseaux, les groupes de sécurité et ENIs les entités associées à un cluster.
+ **`AWS KMS`permission** — est utilisée pour décrire la clé associée au cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"kafka:Describe*",
"kafka:List*",
"kafka:Get*",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"kms:DescribeKey"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
# AWS politique gérée : KafkaServiceRolePolicy
Vous ne pouvez pas vous associer KafkaServiceRolePolicy à vos entités IAM. Cette politique est attachée à un rôle lié à un service qui permet à Amazon MSK d'effectuer des actions telles que la gestion des points de terminaison de VPC (connecteurs) sur les clusters MSK, la gestion des interfaces réseau et la gestion des informations d'identification du cluster avec AWS Secrets Manager. Pour de plus amples informations, veuillez consulter [Rôles liés à un service pour Amazon MSK](using-service-linked-roles.md).
Le tableau suivant décrit les mises à jour apportées à la politique KafkaServiceRolePolicy gérée depuis qu'Amazon MSK a commencé à suivre les modifications.
| Modifier | Description | Date |
| --- | --- | --- |
| [IPv6 prise en charge de la connectivité ajoutée KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy) — Mise à jour d'une politique existante | Amazon MSK a ajouté des autorisations KafkaServiceRolePolicy pour activer la IPv6 connectivité pour les clusters MSK. Ces autorisations permettent à Amazon MSK d'attribuer ou d'annuler l'attribution d' IPv6 adresses aux interfaces réseau et de modifier les attributs des interfaces réseau dans le compte client. | 17 novembre 2025 |
| [KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy) : mise à jour d’une politique existante | Amazon MSK a ajouté des autorisations pour prendre en charge la connectivité privée à plusieurs VPC. | 8 mars 2023 |
| Amazon MSK a commencé à assurer le suivi des modifications | Amazon MSK a commencé à suivre les modifications apportées aux politiques KafkaServiceRolePolicy gérées. | 8 mars 2023 |
# AWS politique gérée : AWSMSKReplicator ExecutionRole
La `AWSMSKReplicatorExecutionRole` politique accorde des autorisations au réplicateur Amazon MSK pour répliquer les données entre les clusters MSK. Les autorisations définies dans cette politique sont regroupées comme suit :
+ **`cluster`**— Accorde à Amazon MSK Replicator l'autorisation de se connecter au cluster à l'aide de l'authentification IAM. Accorde également les autorisations nécessaires pour décrire et modifier le cluster.
+ **`topic`**— Accorde à Amazon MSK Replicator les autorisations nécessaires pour décrire, créer et modifier un sujet, ainsi que pour modifier la configuration dynamique du sujet.
+ **`consumer group`**— Accorde à Amazon MSK Replicator l'autorisation de décrire et de modifier les groupes de consommateurs, de lire et d'écrire la date d'un cluster MSK et de supprimer les sujets internes créés par le réplicateur.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ClusterPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:DescribeCluster",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:*:*:cluster/*"
]
},
{
"Sid": "TopicPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:AlterCluster"
],
"Resource": [
"arn:aws:kafka:*:*:topic/*/*"
]
},
{
"Sid": "GroupPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:*:*:group/*/*"
]
}
]
}
```
------
# Amazon MSK met à jour les politiques AWS gérées
Consultez les informations relatives aux mises à jour des politiques AWS gérées pour Amazon MSK depuis que ce service a commencé à suivre ces modifications.
| Modifier | Description | Date |
| --- | --- | --- |
| [WriteDataIdempotently autorisation ajoutée à AWSMSKReplicator ExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md) — Mise à jour d'une politique existante | Amazon MSK a ajouté WriteDataIdempotently l'autorisation à la AWSMSKReplicator ExecutionRole politique pour prendre en charge la réplication des données entre les clusters MSK. | 12 mars 2024 |
| [AWSMSKReplicatorExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md) : nouvelle politique | Amazon MSK a ajouté une AWSMSKReplicator ExecutionRole politique pour prendre en charge Amazon MSK Replicator. | 4 décembre 2023 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) — Mise à jour d'une politique existante | Amazon MSK a ajouté des autorisations pour prendre en charge le réplicateur Amazon MSK. | 28 septembre 2023 |
| [KafkaServiceRolePolicy](security-iam-awsmanpol-KafkaServiceRolePolicy.md) : mise à jour d’une politique existante | Amazon MSK a ajouté des autorisations pour prendre en charge la connectivité privée à plusieurs VPC. | 8 mars 2023 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) — Mise à jour d'une politique existante | Amazon MSK a ajouté de nouvelles autorisations Amazon EC2 pour permettre la connexion à un cluster. | 30 novembre 2021 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) — Mise à jour d'une politique existante | Amazon MSK a ajouté une nouvelle autorisation lui permettant de décrire les tables de routage Amazon EC2. | 19 novembre 2021 |
| Amazon MSK a commencé à assurer le suivi des modifications | Amazon MSK a commencé à suivre les modifications apportées à ses politiques AWS gérées. | 19 novembre 2021 |
# Résoudre les problèmes liés à l'identité et à l'accès à Amazon MSK
Utilisez les informations suivantes pour identifier et résoudre les problèmes courants que vous pouvez rencontrer lorsque vous utilisez Amazon MSK et IAM.
**Topics**
+ [Je ne suis pas autorisé à effectuer une action dans Amazon MSK](#security_iam_troubleshoot-no-permissions)
## Je ne suis pas autorisé à effectuer une action dans Amazon MSK
S'il vous AWS Management Console indique que vous n'êtes pas autorisé à effectuer une action, vous devez contacter votre administrateur pour obtenir de l'aide. Votre administrateur est la personne qui vous a fourni vos informations de connexion.
L'exemple d'erreur suivant se produit lorsque l'utilisateur IAM `mateojackson` tente d'utiliser la console pour supprimer un cluster, mais ne dispose pas des autorisations `kafka:DeleteCluster`.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: kafka:DeleteCluster on resource: purchaseQueriesCluster
```
Dans ce cas, Mateo demande à son administrateur de mettre à jour ses politiques pour lui permettre d’accéder à la ressource `purchaseQueriesCluster` à l’aide de l’action `kafka:DeleteCluster`.
# Authentification et autorisation pour Apache Kafka APIs
Vous pouvez utiliser IAM pour authentifier les clients et autoriser ou refuser des actions Apache Kafka. Vous pouvez également utiliser le protocole TLS ou SASL/SCRAM pour authentifier les clients, et Apache Kafka ACLs pour autoriser ou refuser des actions.
Pour plus d'informations sur le contrôle des personnes autorisées à effectuer des [opérations Amazon MSK](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html) sur votre cluster, consultez [Authentification et autorisation pour Amazon MSK APIs](security-iam.md).
**Topics**
+ [Contrôle d'accès IAM](iam-access-control.md)
+ [Authentification client TLS mutuelle pour Amazon MSK](msk-authentication.md)
+ [Authentification des identifiants de connexion avec AWS Secrets Manager](msk-password.md)
+ [Apache Kafka ACLs](msk-acls.md)
# Contrôle d'accès IAM
Le contrôle d'accès IAM pour Amazon MSK vous permet de gérer à la fois l'authentification et l'autorisation pour votre cluster MSK. Cela élimine la nécessité d'utiliser un mécanisme unique pour l'authentification et un autre pour l'autorisation. Par exemple, lorsqu'un client tente d'écrire sur votre cluster, Amazon MSK utilise IAM pour vérifier si ce client est une identité authentifiée et s'il est autorisé à produire sur votre cluster.
Le contrôle d'accès IAM fonctionne pour les clients Java et non-Java, y compris les clients Kafka écrits en Python JavaScript, Go et .NET. Le contrôle d'accès IAM pour les clients non-Java est disponible pour les clusters MSK dotés de la version 2.7.1 ou supérieure de Kafka.
Pour rendre le contrôle d'accès IAM possible, Amazon MSK apporte des modifications mineures au code source d'Apache Kafka. Ces modifications n'entraîneront pas de différence notable dans votre expérience avec Apache Kafka. Amazon MSK journalise les événements d'accès afin que vous puissiez les contrôler.
Vous pouvez appeler l'ACL Apache Kafka APIs pour un cluster MSK qui utilise le contrôle d'accès IAM. Cependant, Apache Kafka ACLs n'a aucun effet sur l'autorisation des identités IAM. Vous devez utiliser des politiques IAM pour contrôler l'accès aux identités IAM.
**Considérations importantes**
Lorsque vous utilisez le contrôle d'accès IAM avec votre cluster MSK, gardez à l'esprit les considérations importantes suivantes :
Le contrôle d'accès IAM ne s'applique pas aux ZooKeeper nœuds Apache. Pour plus d'informations sur la manière de contrôler l'accès à ces nœuds, consultez [Contrôlez l'accès aux ZooKeeper nœuds Apache de votre cluster Amazon MSK](zookeeper-security.md).
Le paramètre Apache Kafka `allow.everyone.if.no.acl.found` n'a aucun effet si votre cluster utilise le contrôle d'accès IAM.
Vous pouvez appeler l'ACL Apache Kafka APIs pour un cluster MSK qui utilise le contrôle d'accès IAM. Cependant, Apache Kafka ACLs n'a aucun effet sur l'autorisation des identités IAM. Vous devez utiliser des politiques IAM pour contrôler l'accès aux identités IAM.
# Fonctionnement du contrôle d'accès IAM pour Amazon MSK
Pour utiliser le contrôle d'accès IAM pour Amazon MSK, effectuez les étapes suivantes, décrites en détail dans ces rubriques :
+ [Créez un cluster Amazon MSK qui utilise le contrôle d'accès IAM](create-iam-access-control-cluster-in-console.md)
+ [Configurer les clients pour le contrôle d'accès IAM](configure-clients-for-iam-access-control.md)
+ [Création de politiques d'autorisation pour le rôle IAM](create-iam-access-control-policies.md)
+ [Obtenez les agents d'amorçage pour le contrôle d'accès IAM](get-bootstrap-brokers-for-iam.md)
# Créez un cluster Amazon MSK qui utilise le contrôle d'accès IAM
Cette section explique comment vous pouvez utiliser l' AWS Management Console API ou le AWS CLI pour créer un cluster Amazon MSK qui utilise le contrôle d'accès IAM. Pour plus d'informations sur l'activation du contrôle d'accès IAM pour un cluster existant, consultez [Mettre à jour les paramètres de sécurité d'un cluster Amazon MSK](msk-update-security.md).
**Utilisez le AWS Management Console pour créer un cluster qui utilise le contrôle d'accès IAM**
1. Ouvrez la console Amazon MSK à l'adresse [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Choisissez **Créer un cluster**.
1. Choisissez **Créer un cluster avec des paramètres personnalisés**.
1. Dans la section **Authentification**, choisissez **Contrôle d'accès IAM**.
1. Suivez le reste du flux de travail pour créer un cluster.
**Utilisez l'API ou le AWS CLI pour créer un cluster qui utilise le contrôle d'accès IAM**
+ Pour créer un cluster avec le contrôle d'accès IAM activé, utilisez l'[CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)API ou la commande [create-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/create-cluster.html) CLI et transmettez le JSON suivant pour `ClientAuthentication` le paramètre :. `"ClientAuthentication": { "Sasl": { "Iam": { "Enabled": true } }`
# Configurer les clients pour le contrôle d'accès IAM
Pour permettre aux clients de communiquer avec un cluster MSK qui utilise le contrôle d’accès IAM, vous pouvez utiliser l’un des mécanismes suivants :
+ Configuration d'un client non Java à l'aide d'un mécanisme SASL\$1OAUTHBEARER
+ Configuration du client Java à l'aide d' SASL\$1OAUTHBEARERun mécanisme ou d' AWS\$1MSK\$1IAM un mécanisme
## Utiliser le SASL\$1OAUTHBEARER mécanisme pour configurer IAM
1. Modifiez votre fichier de configuration client.properties à l'aide de l'exemple de client Python Kafka suivant. Les modifications de configuration sont similaires dans les autres langages.
```
from kafka import KafkaProducer
from kafka.errors import KafkaError
from kafka.sasl.oauth import AbstractTokenProvider
import socket
import time
from aws_msk_iam_sasl_signer import MSKAuthTokenProvider
class MSKTokenProvider():
def token(self):
token, _ = MSKAuthTokenProvider.generate_auth_token('')
return token
tp = MSKTokenProvider()
producer = KafkaProducer(
bootstrap_servers='',
security_protocol='SASL_SSL',
sasl_mechanism='OAUTHBEARER',
sasl_oauth_token_provider=tp,
client_id=socket.gethostname(),
)
topic = ""
while True:
try:
inp=input(">")
producer.send(topic, inp.encode())
producer.flush()
print("Produced!")
except Exception:
print("Failed to send message:", e)
producer.close()
```
1. Téléchargez la bibliothèque d'assistance pour la langue de configuration que vous avez choisie et suivez les instructions de la section *Démarrage* de la page d'accueil de cette bibliothèque de langues.
+ JavaScript: [https://github.com/aws/aws-msk-iam-sasl-signer-js](https://github.com/aws/aws-msk-iam-sasl-signer-js#getting-started) \$1getting -started
+ Python : [https://github.com/aws/aws-msk-iam-sasl-signer-python](https://github.com/aws/aws-msk-iam-sasl-signer-python#get-started) \$1get -started
+ Go : [https://github.com/aws/aws-msk-iam-sasl-signer-go](https://github.com/aws/aws-msk-iam-sasl-signer-go#getting-started) \$1getting -started
+ .NET : [https://github.com/aws/aws-msk-iam-sasl-signer-net](https://github.com/aws/aws-msk-iam-sasl-signer-net#getting-started) \$1getting -démarré
+ JAVA : le SASL\$1OAUTHBEARER support de Java est disponible via le fichier [https://github.com/aws/aws-msk-iam-auth/releases](https://github.com/aws/aws-msk-iam-auth/releases)jar
## Utiliser le AWS\$1MSK\$1IAM mécanisme personnalisé MSK pour configurer IAM
1. Ajoutez ce qui suit dans le fichier `client.properties`. **Remplacez-le par le chemin complet vers le fichier Trust Store sur le client.
**Note**
Si vous ne souhaitez pas utiliser un certificat spécifique, vous pouvez supprimer `ssl.truststore.location=` de votre fichier `client.properties`. Si vous ne spécifiez aucune valeur pour `ssl.truststore.location`, le processus Java utilise le certificat par défaut.
```
ssl.truststore.location=
security.protocol=SASL_SSL
sasl.mechanism=AWS_MSK_IAM
sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required;
sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler
```
Pour utiliser un profil nommé que vous avez créé pour les AWS informations d'identification, `awsProfileName="your profile name";` incluez-le dans votre fichier de configuration client. Pour plus d'informations sur les profils nommés, consultez la section [Profils nommés](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html) dans la AWS CLI documentation.
1. Téléchargez le dernier fichier [aws-msk-iam-auth](https://github.com/aws/aws-msk-iam-auth/releases)JAR stable et placez-le dans le chemin de classe. Si vous utilisez Maven, ajoutez la dépendance suivante, en ajustant le numéro de version selon les besoins :
```
software.amazon.msk
aws-msk-iam-auth
1.0.0
```
Le plug-in client Amazon MSK est open source sous la licence Apache 2.0.
# Création de politiques d'autorisation pour le rôle IAM
Attachez une politique d'autorisation au rôle IAM qui correspond au client. Dans une politique d'autorisation, vous spécifiez les actions à autoriser ou à refuser pour le rôle. Si votre client utilise une instance Amazon EC2, associez la politique d'autorisation au rôle IAM pour cette instance Amazon EC2. Vous pouvez également configurer votre client pour qu'il utilise un profil nommé, puis associer la politique d'autorisation au rôle de ce profil nommé. [Configurer les clients pour le contrôle d'accès IAM](configure-clients-for-iam-access-control.md) décrit comment configurer un client pour utiliser un profil nommé.
Pour plus d'informations sur la création d'une politique IAM, consultez [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html).
Voici un exemple de politique d'autorisation pour un cluster nommé MyTestCluster. Pour comprendre la sémantique des éléments `Action` et `Resource`, consultez [Sémantique des politiques d'autorisation, des actions et des ressources de l'IAM](kafka-actions.md).
**Important**
Les modifications que vous apportez à une politique IAM sont reflétées dans l'IAM APIs et immédiatement. AWS CLI Cependant, la modification de la politique peut prendre un certain temps avant d'être effective. Dans la plupart des cas, les modifications de politique prennent effet en moins d'une minute. Les conditions du réseau peuvent parfois augmenter le délai.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster"
],
"Resource": [
"arn:aws:kafka:us-east-1:111122223333:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/*"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:group/MyTestCluster/*"
]
}
]
}
```
------
Pour savoir comment créer une politique avec des éléments d'action correspondant aux cas d'utilisation courants d'Apache Kafka, tels que la production et la consommation de données, consultez [Cas d'utilisation courants de la politique d'autorisation des clients](iam-access-control-use-cases.md).
[Pour les versions 2.8.0 et supérieures de Kafka, l'**WriteDataIdempotently**autorisation est obsolète (KIP-679).](https://cwiki.apache.org/confluence/display/KAFKA/KIP-679%3A+Producer+will+enable+the+strongest+delivery+guarantee+by+default) Par défaut, `enable.idempotence = true` est défini. Par conséquent, pour les versions 2.8.0 et supérieures de Kafka, IAM n'offre pas les mêmes fonctionnalités que Kafka. ACLs Il n'est pas possible d'accéder `WriteDataIdempotently` à un sujet en fournissant uniquement `WriteData` l'accès à ce sujet. Cela n'affecte pas le cas lorsqu'il `WriteData` est fourni à **TOUS les** sujets. Dans ce cas, `WriteDataIdempotently` est autorisé. Cela est dû à des différences dans la mise en œuvre de la logique IAM et dans la manière dont les Kafka ACLs sont implémentés. De plus, écrire sur un sujet de manière idiote nécessite également un accès à. `transactional-ids`
Pour contourner ce problème, nous vous recommandons d'utiliser une politique similaire à la suivante.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/TestTopic",
"arn:aws:kafka:us-east-1:123456789012:transactional-id/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*"
]
}
]
}
```
------
Dans ce cas, `WriteData` autorise les écritures vers la `TestTopic`, pendant que `WriteDataIdempotently` autorise les écritures idempotentes sur le cluster. Cette politique ajoute également l'accès aux `transactional-id` ressources qui seront nécessaires.
Comme il `WriteDataIdempotently` s'agit d'une autorisation au niveau du cluster, vous ne pouvez pas l'utiliser au niveau du sujet. Si elle `WriteDataIdempotently` est limitée au niveau du sujet, cette politique ne fonctionnera pas.
# Obtenez les agents d'amorçage pour le contrôle d'accès IAM
Consultez [Obtenez les courtiers bootstrap pour un cluster Amazon MSK](msk-get-bootstrap-brokers.md).
# Sémantique des politiques d'autorisation, des actions et des ressources de l'IAM
**Note**
Pour les clusters exécutant Apache Kafka version 3.8 ou ultérieure, le contrôle d'accès IAM prend en charge l' WriteTxnMarkers API pour mettre fin aux transactions. Pour les clusters exécutant des versions de Kafka antérieures à 3.8, le contrôle d'accès IAM ne prend pas en charge les actions internes du cluster, notamment. WriteTxnMarkers Pour ces versions antérieures, pour mettre fin aux transactions, utilisez l'authentification SCRAM ou mTLS avec une authentification appropriée ACLs au lieu de l'authentification IAM.
Cette section explique la sémantique des éléments d'action et de ressource que vous pouvez utiliser dans une politique d'autorisation IAM. Pour un exemple de politique, consultez [Création de politiques d'autorisation pour le rôle IAM](create-iam-access-control-policies.md).
## Actions relatives à la politique d'autorisation
Le tableau suivant répertorie les actions que vous pouvez inclure dans une politique d'autorisation lorsque vous utilisez le contrôle d'accès IAM pour Amazon MSK. Lorsque vous incluez dans votre politique d'autorisation une action de la colonne *Action* du tableau, vous devez également inclure les actions correspondantes de la colonne *Actions requises*.
| Action | Description | Actions requises | Ressources requises | Applicable aux clusters sans serveur |
| --- | --- | --- | --- | --- |
| kafka-cluster:Connect | Octroie l'autorisation de se connecter et de s'authentifier à un cluster. | Aucune | cluster | Oui |
| kafka-cluster:DescribeCluster | Octroie l'autorisation de décrire divers aspects du cluster, équivalent à l'ACL DESCRIBE CLUSTER d'Apache Kafka. | `kafka-cluster:Connect` | cluster | Oui |
| kafka-cluster:AlterCluster | Octroi l'autorisation de modifier divers aspects du cluster, équivalent à l'ACL ALTER CLUSTER d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeCluster` | cluster | Non |
| kafka-cluster:DescribeClusterDynamicConfiguration | Octroie l'autorisation de décrire la configuration dynamique d'un cluster, équivalent à l'ACL DESCRIBE\$1CONFIGS CLUSTER d'Apache Kafka. | `kafka-cluster:Connect` | cluster | Non |
| kafka-cluster:AlterClusterDynamicConfiguration | Octroie l'autorisation de modifier la configuration dynamique d'un cluster, équivalente à l'ACL ALTER\$1CONFIGS CLUSTER d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` | cluster | Non |
| kafka-cluster:WriteDataIdempotently | Octroie l'autorisation d'écrire des données de manière idempotente dans un cluster, équivalent à l'ACL IDEMPOTENT\$1WRITE CLUSTER d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:WriteData` | cluster | Oui |
| kafka-cluster:CreateTopic | Accorde l'autorisation de créer des sujets sur un cluster, ce qui est équivalent à l' CLUSTER/TOPIC ACL CREATE d'Apache Kafka. | `kafka-cluster:Connect` | topic | Oui |
| kafka-cluster:DescribeTopic | Octroie l'autorisation de décrire des rubriques dans un cluster, équivalent à l'ACL DESCRIBE TOPIC d'Apache Kafka. | `kafka-cluster:Connect` | topic | Oui |
| kafka-cluster:AlterTopic | Octroie l'autorisation de modifier des rubriques dans un cluster, équivalent à l'ACL ALTER TOPIC d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | topic | Oui |
| kafka-cluster:DeleteTopic | Octroie l'autorisation de supprimer des rubriques dans un cluster, équivalent à l'ACL DELETE TOPIC d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | topic | Oui |
| kafka-cluster:DescribeTopicDynamicConfiguration | Octroie l'autorisation de décrire la configuration dynamique des rubriques dans un cluster, équivalent à l'ACL DESCRIBE\$1CONFIGS TOPIC d'Apache Kafka. | `kafka-cluster:Connect` | topic | Oui |
| kafka-cluster:AlterTopicDynamicConfiguration | Octroie l'autorisation de modifier la configuration dynamique des rubriques dans un cluster, équivalent à l'ACL ALTER\$1CONFIGS TOPIC d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` | topic | Oui |
| kafka-cluster:ReadData | Octroie l'autorisation de lire des données provenant de rubriques dans un cluster, équivalent à l'ACL READ TOPIC d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterGroup` | topic | Oui |
| kafka-cluster:WriteData | Autorise l'écriture des données dans les rubriques d'un cluster, équivalent à l'ACL WRITE TOPIC d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | topic | Oui |
| kafka-cluster:DescribeGroup | Octroie l'autorisation de décrire des groupes dans un cluster, équivalent à l'ACL DESCRIBE GROUP d'Apache Kafka. | `kafka-cluster:Connect` | groupe | Oui |
| kafka-cluster:AlterGroup | Octroie l'autorisation de rejoindre des groupes dans un cluster, équivalent à l'ACL READ GROUP d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | groupe | Oui |
| kafka-cluster:DeleteGroup | Octroie l'autorisation de supprimer des groupes d'un cluster, équivalent à l'ACL DELETE GROUP d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | groupe | Oui |
| kafka-cluster:DescribeTransactionalId | Accorde l'autorisation de décrire les transactions IDs sur un cluster, ce qui est équivalent à l'ACL DESCRIBE TRANSACTIONAL\$1ID d'Apache Kafka. | `kafka-cluster:Connect` | transactional-id | Oui |
| kafka-cluster:AlterTransactionalId | Accorde l'autorisation de modifier les transactions IDs sur un cluster, ce qui est équivalent à l'ACL WRITE TRANSACTIONAL\$1ID d'Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:WriteData` | transactional-id | Oui |
Vous pouvez utiliser le caractère générique astérisque (\$1) autant de fois que vous le souhaitez dans une action après deux points. Voici quelques exemples.
+ `kafka-cluster:*Topic` représente `kafka-cluster:CreateTopic`, `kafka-cluster:DescribeTopic`, `kafka-cluster:AlterTopic` et `kafka-cluster:DeleteTopic`. Cela n'inclut pas `kafka-cluster:DescribeTopicDynamicConfiguration` ou `kafka-cluster:AlterTopicDynamicConfiguration`.
+ `kafka-cluster:*` représente toutes les autorisations.
## Ressources relatives aux politiques d'autorisation
Le tableau suivant montre les quatre types de ressources que vous pouvez utiliser dans une politique d'autorisation lorsque vous utilisez le contrôle d'accès IAM pour Amazon MSK. Vous pouvez obtenir le nom de ressource Amazon (ARN) du cluster à partir du AWS Management Console ou en utilisant l'[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)API ou la commande [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html) AWS CLI . Vous pouvez ensuite utiliser l'ARN du cluster pour créer un identifiant ARNs de sujet, de groupe et de transaction. Pour spécifier une ressource dans une politique d'autorisation, utilisez l'ARN de cette ressource.
| Ressource | Format ARN |
| --- | --- |
| Cluster | arn:aws:kafka : ::cluster//regionaccount-idcluster-namecluster-uuid |
| Rubrique | arn:aws:kafka : ::topic//regionaccount-idcluster-namecluster-uuidtopic-name |
| Groupe | arn:aws:kafka : :group///regionaccount-idcluster-namecluster-uuidgroup-name |
| ID transactionnel | arn:aws:kafka : :transactional-id//regionaccount-idcluster-namecluster-uuidtransactional-id |
Vous pouvez utiliser le caractère générique astérisque (\$1) autant de fois que vous le souhaitez dans la partie de l'ARN située après `:cluster/`, `:topic/`, `:group/` et `:transactional-id/`. Les exemples suivants illustrent la manière dont vous pouvez utiliser le caractère générique astérisque (\$1) pour faire référence à plusieurs ressources :
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/*`: tous les sujets d'un cluster nommé MyTestCluster, quel que soit l'UUID du cluster.
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*_test`: toutes les rubriques dont le nom se termine par « \$1test » dans le cluster dont le nom est MyTestCluster et dont l'UUID est abcd1234-0123-abcd-5678-1234abcd-1.
+ `arn:aws:kafka:us-east-1:0123456789012:transactional-id/MyTestCluster/*/5555abcd-1111-abcd-1234-abcd1234-1`: toutes les transactions dont l'ID transactionnel est 5555abcd-1111-abcd-1234-abcd1234-1, dans toutes les incarnations d'un cluster nommé dans votre compte. MyTestCluster Cela signifie que si vous créez un cluster nommé MyTestCluster, que vous le supprimez, puis que vous créez un autre cluster portant le même nom, vous pouvez utiliser cet ARN de ressource pour représenter le même identifiant de transaction sur les deux clusters. Cependant, le cluster supprimé n'est pas accessible.
# Cas d'utilisation courants de la politique d'autorisation des clients
La première colonne du tableau suivant présente certains cas d'utilisation courants. Pour autoriser un client à exécuter un cas d'utilisation donné, incluez les actions requises pour ce cas d'utilisation dans la politique d'autorisation du client et définissez `Effect` sur `Allow`.
Pour plus d'informations sur toutes les actions faisant partie du contrôle d'accès IAM pour Amazon MSK, consultez [Sémantique des politiques d'autorisation, des actions et des ressources de l'IAM](kafka-actions.md).
**Note**
Les actions sont refusées par défaut. Vous devez autoriser explicitement chaque action que vous souhaitez autoriser le client à effectuer.
****
| Cas d’utilisation | Actions requises |
| --- | --- |
| Admin | `kafka-cluster:*` |
| Création d’une rubrique | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` |
| Produire des données | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` |
| Consommer des données | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeGroup` `kafka-cluster:AlterGroup` `kafka-cluster:ReadData` |
| Produire des données de manière idempotente | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:WriteDataIdempotently` |
| Produire des données de manière transactionnelle | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:AlterTransactionalId` |
| Décrire la configuration d'un cluster | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` |
| Mettre à jour la configuration d'un cluster | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` `kafka-cluster:AlterClusterDynamicConfiguration` |
| Décrire la configuration d'une rubrique | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` |
| Mettre à jour la configuration d'une rubrique | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` `kafka-cluster:AlterTopicDynamicConfiguration` |
| Modifier une rubrique | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` |
# Authentification client TLS mutuelle pour Amazon MSK
Vous pouvez activer l'authentification client avec TLS pour les connexions entre vos applications et vos courtiers Amazon MSK. Pour utiliser l'authentification client, vous avez besoin d'une Autorité de certification privée AWS. Ils Autorité de certification privée AWS peuvent se trouver dans le même compte Compte AWS que celui de votre cluster ou dans un autre compte. Pour plus d'informations sur Autorité de certification privée AWS s, voir [Création et gestion d'un Autorité de certification privée AWS](https://docs.aws.amazon.com/acm-pca/latest/userguide/create-CA.html).
Amazon MSK ne prend pas en charge les listes de révocation de certificats ()CRLs. Pour contrôler l'accès aux rubriques de votre cluster ou bloquer les certificats compromis, utilisez Apache Kafka ACLs et les groupes AWS de sécurité. Pour plus d'informations sur l'utilisation d'Apache Kafka ACLs, consultez[Apache Kafka ACLs](msk-acls.md).
**Topics**
+ [Créez un cluster Amazon MSK qui prend en charge l'authentification des clients](msk-authentication-cluster.md)
+ [Configurer un client pour qu'il utilise l'authentification](msk-authentication-client.md)
+ [Produire et consommer des messages à l'aide de l'authentification](msk-authentication-messages.md)
# Créez un cluster Amazon MSK qui prend en charge l'authentification des clients
Cette procédure explique comment activer l'authentification du client à l'aide d'un Autorité de certification privée AWS.
**Note**
Nous vous recommandons vivement d'utiliser le protocole indépendant Autorité de certification privée AWS pour chaque cluster MSK lorsque vous utilisez le protocole TLS mutuel pour contrôler l'accès. Cela garantira que les certificats TLS signés par PCAs ne s'authentifient qu'auprès d'un seul cluster MSK.
1. Créez un fichier nommé `clientauthinfo.json` avec les contenus suivants. *Private-CA-ARN*Remplacez-le par l'ARN de votre PCA.
```
{
"Tls": {
"CertificateAuthorityArnList": ["Private-CA-ARN"]
}
}
```
1. Créez un fichier nommé `brokernodegroupinfo.json` comme décrit à la section [Créez un cluster Amazon MSK provisionné à l'aide du AWS CLI](create-cluster-cli.md).
1. L'authentification du client nécessite également l'activation du chiffrement lors du transit entre les clients et les brokers. Créez un fichier nommé `encryptioninfo.json` avec les contenus suivants. *KMS-Key-ARN*Remplacez-le par l'ARN de votre clé KMS. Vous pouvez définir `ClientBroker` sur `TLS` ou `TLS_PLAINTEXT`.
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "KMS-Key-ARN"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
iPour de plus amples informations sur le chiffrement, veuillez consulter [Chiffrement Amazon MSK](msk-encryption.md).
1. Sur une machine sur laquelle vous l'avez AWS CLI installé, exécutez la commande suivante pour créer un cluster sur lequel l'authentification et le chiffrement en transit sont activés. Enregistrez l'ARN de cluster fourni dans la réponse.
```
aws kafka create-cluster --cluster-name "AuthenticationTest" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --client-authentication file://clientauthinfo.json --kafka-version "{YOUR KAFKA VERSION}" --number-of-broker-nodes 3
```
# Configurer un client pour qu'il utilise l'authentification
Ce processus décrit comment configurer une instance Amazon EC2 à utiliser en tant que client pour utiliser l'authentification.
Ce processus décrit comment produire et consommer des messages à l'aide de l'authentification en créant une machine cliente, en créant un sujet et en configurant les paramètres de sécurité requis.
1. Créez une instance Amazon EC2 à utiliser en tant qu'ordinateur client. Pour plus de simplicité, créez cette instance dans le même VPC que celui utilisé pour le cluster. Consultez [Étape 3 : Créer un ordinateur client](create-client-machine.md) pour un exemple de création d'une machine client.
1. Créer une rubrique. Pour obtenir un exemple, consultez les instructions dans [Étape 4 : créer une rubrique dans le cluster Amazon MSK](create-topic.md).
1. Sur une machine sur laquelle vous l'avez AWS CLI installé, exécutez la commande suivante pour obtenir les courtiers bootstrap du cluster. *Cluster-ARN*Remplacez-le par l'ARN de votre cluster.
```
aws kafka get-bootstrap-brokers --cluster-arn Cluster-ARN
```
Enregistrez la chaîne associée à `BootstrapBrokerStringTls` dans la réponse.
1. Sur votre ordinateur client, exécutez la commande suivante pour utiliser le magasin de confiance JVM pour créer votre magasin de confiance client. Si votre chemin JVM est différent, ajustez la commande en conséquence.
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts kafka.client.truststore.jks
```
1. Sur votre ordinateur client, exécutez la commande suivante pour créer une clé privée pour votre client. Remplacez *Distinguished-Name**Example-Alias*,*Your-Store-Pass*, et *Your-Key-Pass* par les chaînes de votre choix.
```
keytool -genkey -keystore kafka.client.keystore.jks -validity 300 -storepass Your-Store-Pass -keypass Your-Key-Pass -dname "CN=Distinguished-Name" -alias Example-Alias -storetype pkcs12 -keyalg rsa
```
1. Sur votre ordinateur client, exécutez la commande suivante pour créer une demande de certificat avec la clé privée que vous avez créée à l'étape précédente.
```
keytool -keystore kafka.client.keystore.jks -certreq -file client-cert-sign-request -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. Ouvrez le fichier `client-cert-sign-request` et assurez-vous qu'il commence par `-----BEGIN CERTIFICATE REQUEST-----` et se termine par `-----END CERTIFICATE REQUEST-----`. Si elle commence par `-----BEGIN NEW CERTIFICATE REQUEST-----`, supprimez le mot `NEW` (et l'espace unique qui le suit) du début et de la fin du fichier.
1. Sur une machine sur laquelle vous l'avez AWS CLI installé, exécutez la commande suivante pour signer votre demande de certificat. *Private-CA-ARN*Remplacez-le par l'ARN de votre PCA. Vous pouvez modifier la valeur de validité si vous le souhaitez. Ici, nous utilisons 300 comme exemple.
```
aws acm-pca issue-certificate --certificate-authority-arn Private-CA-ARN --csr fileb://client-cert-sign-request --signing-algorithm "SHA256WITHRSA" --validity Value=300,Type="DAYS"
```
Enregistrez l'ARN de certificat fourni dans la réponse.
**Note**
Pour récupérer votre certificat client, utilisez la commande `acm-pca get-certificate` et spécifiez l'ARN de votre certificat. Pour plus d'informations, consultez [get-certificate](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm-pca/get-certificate.html) dans la *Référence des commandes AWS CLI *.
1. Exécutez la commande suivante pour obtenir le certificat qui Autorité de certification privée AWS a été signé pour vous. *Certificate-ARN*Remplacez-le par l'ARN que vous avez obtenu à partir de la réponse à la commande précédente.
```
aws acm-pca get-certificate --certificate-authority-arn Private-CA-ARN --certificate-arn Certificate-ARN
```
1. À partir du résultat JSON de l'exécution de la commande précédente, copiez les chaînes associées à `Certificate` et `CertificateChain`. Collez ces deux chaînes dans un nouveau fichier nommé signed-certificate-from-acm. Collez la chaîne associée à `Certificate` en premier, suivie de la chaîne associée à `CertificateChain`. Remplacez les caractères `\n` par de nouvelles lignes. Voici la structure du fichier après avoir collé le certificat et la chaîne de certificats.
```
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
1. Exécutez la commande suivante sur l’ordinateur client pour ajouter ce certificat à votre magasin de clés afin que vous puissiez le présenter lorsque vous parlez aux agents MSK.
```
keytool -keystore kafka.client.keystore.jks -import -file signed-certificate-from-acm -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. Créez un fichier nommé `client.properties` avec les contenus suivants. Ajustez les emplacements du magasin de confiance et du magasin de clés aux chemins d'accès où vous avez enregistré `kafka.client.truststore.jks`. Remplacez les *\$1YOUR KAFKA VERSION\$1* espaces réservés par la version de votre client Kafka.
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.truststore.jks
ssl.keystore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.keystore.jks
ssl.keystore.password=Your-Store-Pass
ssl.key.password=Your-Key-Pass
```
# Produire et consommer des messages à l'aide de l'authentification
Ce processus décrit comment produire et consommer des messages à l'aide de l'authentification.
1. Exécutez la commande suivante pour créer une rubrique. Le fichier nommé `client.properties` est celui que vous avez créé lors de la procédure précédente.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBroker-String --replication-factor 3 --partitions 1 --topic ExampleTopic --command-config client.properties
```
1. Exécutez la commande suivante pour démarrer un producteur de console. Le fichier nommé `client.properties` est celui que vous avez créé lors de la procédure précédente.
```
/bin/kafka-console-producer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --producer.config client.properties
```
1. Dans une nouvelle fenêtre de commande sur votre ordinateur client, exécutez la commande suivante pour démarrer un consommateur de console.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --consumer.config client.properties
```
1. Tapez des messages dans la fenêtre du producteur et regardez-les apparaître dans la fenêtre du consommateur.
# Authentification des identifiants de connexion avec AWS Secrets Manager
Vous pouvez contrôler l'accès à vos clusters Amazon MSK à l'aide d'informations de connexion stockées et sécurisées à l'aide de AWS Secrets Manager. Le stockage des informations d'identification des utilisateurs dans Secrets Manager réduit les coûts liés à l'authentification du cluster, comme l'audit, la mise à jour et la rotation des informations d'identification. Secrets Manager vous permet également de partager les informations d'identification des utilisateurs entre les clusters.
Après avoir associé un secret à un cluster MSK, MSK synchronise régulièrement les données d'identification.
**Topics**
+ [Comment fonctionne l'authentification des informations de connexion](msk-password-howitworks.md)
+ [Configurer SASL/SCRAM l'authentification pour un cluster Amazon MSK](msk-password-tutorial.md)
+ [Utilisation des utilisateurs](msk-password-users.md)
+ [Limitations liées à l'utilisation des secrets SCRAM](msk-password-limitations.md)
# Comment fonctionne l'authentification des informations de connexion
L'authentification des informations de connexion pour Amazon MSK utilise l'authentification SASL/SCRAM (Simple Authentication and Security Layer/Salted Challenge Response Mechanism). Pour configurer l'authentification des informations d'identification de connexion pour un cluster, vous devez créer une ressource secrète dans [AWS Secrets Manager](https://docs.aws.amazon.com//secretsmanager/?id=docs_gateway) et associer les informations d'identification de connexion à ce secret.
L'authentification SASL/SCRAM est définie dans [RFC 5802.](https://tools.ietf.org/html/rfc5802) SCRAM utilise des algorithmes de hachage sécurisés et ne transmet pas d'informations d'identification de connexion en texte brut entre le client et le serveur.
**Note**
Lorsque vous configurez SASL/SCRAM l'authentification pour votre cluster, Amazon MSK active le chiffrement TLS pour tout le trafic entre les clients et les courtiers.
# Configurer SASL/SCRAM l'authentification pour un cluster Amazon MSK
Pour configurer un secret dans AWS Secrets Manager, suivez le didacticiel de [création et de récupération d'un secret figurant](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) dans le [guide de l'utilisateur de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html).
Tenez compte des exigences suivantes lors de la création d'un secret pour un cluster Amazon MSK :
+ Choisissez **Autre type de secrets (p. ex. clé d'API)** pour le type de secret.
+ Votre nom secret doit commencer par le préfixe **AmazonMSK\$1**.
+ Vous devez soit utiliser une AWS KMS clé personnalisée existante, soit créer une nouvelle AWS KMS clé personnalisée pour votre secret. Secrets Manager utilise la AWS KMS clé par défaut pour un secret.
**Important**
Un secret créé avec la AWS KMS clé par défaut ne peut pas être utilisé avec un cluster Amazon MSK.
+ Vos informations d'identification de connexion doivent être au format suivant pour saisir des paires clé-valeur à l'aide de l'option **Texte brut**.
```
{
"username": "alice",
"password": "alice-secret"
}
```
+ Enregistrez la valeur ARN (Amazon Resource Name) de votre secret.
+
**Important**
Vous ne pouvez pas associer un secret de Secrets Manager à un cluster qui dépasse les limites décrites dans [Dimensionnez correctement votre cluster : nombre de partitions par courtier standard](bestpractices.md#partitions-per-broker).
+ Si vous utilisez le AWS CLI pour créer le secret, spécifiez un ID de clé ou un ARN pour le `kms-key-id` paramètre. Ne spécifiez pas d'alias.
+ Pour associer le secret à votre cluster, utilisez soit la console Amazon MSK, soit l'[ BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret)opération.
**Important**
Lorsque vous associez un secret à un cluster, Amazon MSK associe une politique de ressource au secret qui permet à votre cluster d'accéder aux valeurs secrètes que vous avez définies et de les lire. Vous ne devez pas modifier cette politique de ressource. Cela peut empêcher votre cluster d'accéder à votre secret. Si vous apportez des modifications à la politique de ressources Secrets et/ou à la clé KMS utilisée pour le chiffrement secret, assurez-vous de réassocier les secrets à votre cluster MSK. Cela permettra à votre cluster de continuer à accéder à votre secret.
L'exemple d'entrée JSON suivant pour l'opération `BatchAssociateScramSecret` associe un secret à un cluster :
```
{
"clusterArn" : "arn:aws:kafka:us-west-2:0123456789019:cluster/SalesCluster/abcd1234-abcd-cafe-abab-9876543210ab-4",
"secretArnList": [
"arn:aws:secretsmanager:us-west-2:0123456789019:secret:AmazonMSK_MyClusterSecret"
]
}
```
# Connexion à votre cluster à l'aide des informations d'identification de connexion
Après avoir créé un secret et l'avoir associé à votre cluster, vous pouvez connecter votre client au cluster. La procédure suivante montre comment connecter un client à un cluster utilisant l' SASL/SCRAM authentification. Il montre également comment produire et consommer à partir d'un exemple de sujet.
**Topics**
+ [Connexion d'un client au cluster à l'aide de l' SASL/SCRAM authentification](#w2aab9c13c29c17c13c11b9b7)
+ [Dépannage des problèmes de connexion](#msk-password-tutorial-connect-troubleshooting)
## Connexion d'un client au cluster à l'aide de l' SASL/SCRAM authentification
1. Exécutez la commande suivante sur une machine déjà AWS CLI installée. *clusterARN*Remplacez-le par l'ARN de votre cluster.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
À partir du résultat JSON de cette commande, enregistrez la valeur associée à la chaîne nommée`BootstrapBrokerStringSaslScram`. Vous utiliserez cette valeur dans les étapes suivantes.
1. Sur votre ordinateur client, créez un fichier de configuration JAAS contenant les informations d'identification d'utilisateur stockées dans votre secret. Par exemple, pour l'utilisateur **alice**, créez un fichier appelé `users_jaas.conf` avec le contenu suivant.
```
KafkaClient {
org.apache.kafka.common.security.scram.ScramLoginModule required
username="alice"
password="alice-secret";
};
```
1. Utilisez la commande suivante pour exporter votre fichier de configuration JAAS en tant que paramètre d'environnement `KAFKA_OPTS`.
```
export KAFKA_OPTS=-Djava.security.auth.login.config=/users_jaas.conf
```
1. Créez un fichier nommé `kafka.client.truststore.jks` dans un répertoire `/tmp`.
1. (Facultatif) Utilisez la commande suivante pour copier le fichier de stockage de clés JDK de votre `cacerts` dossier JVM dans le `kafka.client.truststore.jks` fichier que vous avez créé à l'étape précédente. *JDKFolder*Remplacez-le par le nom du dossier JDK de votre instance. Par exemple, votre dossier JDK peut être nommé `java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64`.
```
cp /usr/lib/jvm/JDKFolder/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. Dans le répertoire `bin` de votre installation d'Apache Kafka, créez un fichier de propriétés client appelé `client_sasl.properties` avec le contenu suivant. Ce fichier définit le mécanisme et le protocole SASL.
```
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
```
1. Pour créer un exemple de rubrique, exécutez la commande suivante. *BootstrapBrokerStringSaslScram*Remplacez-la par la chaîne bootstrap broker que vous avez obtenue à l'étape 1 de cette rubrique.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBrokerStringSaslScram --command-config /client_sasl.properties --replication-factor 3 --partitions 1 --topic ExampleTopicName
```
1. Pour produire un exemple de rubrique que vous avez créé, exécutez la commande suivante sur votre ordinateur client. *BootstrapBrokerStringSaslScram*Remplacez-la par la chaîne du broker bootstrap que vous avez récupérée à l'étape 1 de cette rubrique.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringSaslScram --topic ExampleTopicName --producer.config client_sasl.properties
```
1. Pour consommer à partir de la rubrique que vous avez créée, exécutez la commande suivante sur votre ordinateur client. *BootstrapBrokerStringSaslScram*Remplacez-la par la chaîne bootstrap broker que vous avez obtenue à l'étape 1 de cette rubrique.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --from-beginning --consumer.config client_sasl.properties
```
## Dépannage des problèmes de connexion
Lorsque vous exécutez les commandes du client Kafka, vous pouvez rencontrer des erreurs de mémoire Java Heap, en particulier lorsque vous travaillez avec des sujets ou des ensembles de données volumineux. Ces erreurs se produisent parce que les outils Kafka s'exécutent en tant qu'applications Java avec des paramètres de mémoire par défaut qui peuvent être insuffisants pour votre charge de travail.
Pour résoudre `Out of Memory Java Heap` les erreurs, vous pouvez augmenter la taille du segment de mémoire Java en modifiant la variable d'`KAFKA_OPTS`environnement pour inclure les paramètres de mémoire.
L'exemple suivant définit la taille maximale du tas à 1 Go ()`-Xmx1G`. Vous pouvez ajuster cette valeur en fonction de la mémoire système disponible et de vos exigences.
```
export KAFKA_OPTS="-Djava.security.auth.login.config=/users_jaas.conf -Xmx1G"
```
Si vous abordez des sujets volumineux, pensez à utiliser des paramètres basés sur le temps ou le décalage plutôt que de limiter l'utilisation `--from-beginning` de la mémoire :
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --max-messages 1000 --consumer.config client_sasl.properties
```
# Utilisation des utilisateurs
**Création d'utilisateurs :** vous créez des utilisateurs dans votre secret sous forme de paires valeur-clé. Lorsque vous utilisez l'option **Texte brut** dans la console Secrets Manager, vous devez spécifier les informations d'identification de connexion au format suivant.
```
{
"username": "alice",
"password": "alice-secret"
}
```
**Révocation de l'accès utilisateur :** pour révoquer les informations d'identification d'un utilisateur lui permettant d'accéder à un cluster, nous vous recommandons de supprimer ou d'appliquer une liste de contrôle d'accès (ACL) sur le cluster, puis de dissocier le secret. Ceci pour les raisons suivantes :
+ La suppression d'un utilisateur ne ferme pas les connexions existantes.
+ Les modifications de votre secret prennent jusqu'à 10 minutes pour se propager.
Pour en savoir plus sur l'utilisation d'une liste de contrôle d'accès (ACL) avec Amazon MSK, consultez [Apache Kafka ACLs](msk-acls.md).
Pour les clusters utilisant ZooKeeper le mode, nous vous recommandons de restreindre l'accès à vos ZooKeeper nœuds afin d'empêcher les utilisateurs de les modifier ACLs. Pour de plus amples informations, veuillez consulter [Contrôlez l'accès aux ZooKeeper nœuds Apache de votre cluster Amazon MSK](zookeeper-security.md).
# Limitations liées à l'utilisation des secrets SCRAM
Notez les limitations suivantes lorsque vous utilisez des secrets SCRAM :
+ Amazon MSK prend uniquement en charge l'authentification SCRAM-SHA-512.
+ Un cluster Amazon MSK peut avoir jusqu'à 1 000 utilisateurs.
+ Vous devez utiliser un AWS KMS key avec votre secret. Vous ne pouvez pas utiliser un secret qui utilise la clé de chiffrement par défaut de Secrets Manager avec Amazon MSK. Pour plus d'informations sur la création d'une clé KMS, consultez [Création de clés de chiffrements symétriques](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk).
+ Vous ne pouvez pas utiliser une clé KMS asymétrique avec Secrets Manager.
+ Vous pouvez associer jusqu'à 10 secrets à un cluster à la fois à l'aide de cette [ BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret)opération.
+ Le nom des secrets associés à un cluster Amazon MSK doit comporter le préfixe **AmazonMSK\$1**.
+ Les secrets associés à un cluster Amazon MSK doivent se trouver dans le même compte Amazon Web Services et dans la même AWS région que le cluster.
# Apache Kafka ACLs
Apache Kafka possède un autorisateur enfichable et est livré avec une implémentation d'autorisateur. out-of-box Amazon MSK active ce mécanisme d’autorisation dans le fichier `server.properties` sur les brokers.
Apache Kafka ACLs a le format « Le P principal est [autorisé/refusé] Opération O depuis l'hôte H sur toute ressource R correspondant au RP ». ResourcePattern Si RP ne correspond pas à une ressource R spécifique, alors R n'est pas associée et ACLs, par conséquent, personne d'autre que les super utilisateurs n'est autorisé à accéder à R. Pour modifier ce comportement d'Apache Kafka, vous définissez la propriété sur `allow.everyone.if.no.acl.found` true. Amazon MSK la définit par défaut en tant que vrai. Cela signifie qu'avec les clusters Amazon MSK, si vous ne définissez ACLs pas explicitement une ressource, tous les principaux peuvent accéder à cette ressource. Si vous l'activez ACLs sur une ressource, seuls les principaux autorisés peuvent y accéder. Si vous souhaitez restreindre l'accès à une rubrique et autoriser un client à l'aide de l'authentification mutuelle TLS, ajoutez-la à l' ACLs aide de la CLI d'autorisation Apache Kafka. Pour plus d'informations sur l'ajout, la suppression et la mise en liste ACLs, consultez l'[interface de ligne de commande d'autorisation Kafka](https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Authorization+Command+Line+Interface).
Amazon MSK configurant les courtiers en tant que super utilisateurs, ils peuvent accéder à toutes les rubriques. Cela permet aux courtiers de répliquer les messages depuis la partition principale, que la `allow.everyone.if.no.acl.found` propriété soit définie ou non pour la configuration du cluster.
**Pour ajouter ou supprimer l'accès en lecture et en écriture à une rubrique**
1. Ajoutez vos courtiers au tableau ACL pour leur permettre de lire tous les sujets ACLs en place. Pour donner l'accès à vos agents à la lecture d'une rubrique, exécutez la commande suivante sur un ordinateur client qui peut communiquer avec le cluster MSK.
Remplacez *Distinguished-Name* par le DNS de l'un des courtiers bootstrap de votre cluster, puis remplacez la chaîne située avant le premier point de ce nom distinctif par un astérisque ()`*`. Par exemple, si l'un des courtiers bootstrap de votre cluster possède le DNS`b-6.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com`, remplacez *Distinguished-Name* la commande suivante par`*.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com`. Pour de plus amples informations sur la façon d'obtenir les brokers d’amorçage, veuillez consulter [Obtenez les courtiers bootstrap pour un cluster Amazon MSK](msk-get-bootstrap-brokers.md).
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
1. Pour accorder à une application cliente un accès en lecture à une rubrique, exécutez la commande suivante sur votre ordinateur client. Si vous utilisez l'authentification TLS mutuelle, utilisez celle *Distinguished-Name* que vous avez utilisée lors de la création de la clé privée.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
Pour supprimer l'accès en lecture, vous pouvez exécuter la même commande, en remplaçant `--add` par `--remove`.
1. Pour accorder un accès en écriture à une rubrique, exécutez la commande suivante sur votre ordinateur client. Si vous utilisez l'authentification TLS mutuelle, utilisez celle *Distinguished-Name* que vous avez utilisée lors de la création de la clé privée.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Write --topic Topic-Name
```
Pour supprimer l'accès en écriture, vous pouvez exécuter la même commande, en remplaçant `--add` par `--remove`.
# Modification du groupe de sécurité d'un cluster Amazon MSK
Cette page explique comment modifier le groupe de sécurité d'un cluster MSK existant. Vous devrez peut-être modifier le groupe de sécurité d'un cluster afin de fournir l'accès à un certain ensemble d'utilisateurs ou de limiter l'accès au cluster. Pour plus d'informations sur les groupes de sécurité, consultez [Groupes de sécurité pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) dans le Guide de l'utilisateur Amazon VPC.
1. Utilisez l'[ListNodes](https://docs.amazonaws.cn/en_us/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes)API ou la commande [list-nodes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/list-nodes.html) du AWS CLI pour obtenir la liste des courtiers de votre cluster. Les résultats de cette opération incluent les IDs interfaces réseau élastiques (ENIs) associées aux courtiers.
1. Connectez-vous à la console Amazon EC2 AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. À l'aide de la liste déroulante située dans le coin supérieur droit de l'écran, sélectionnez la région dans laquelle le cluster est déployé.
1. Dans le volet de navigation, sous **Réseau et sécurité**, choisissez **Interfaces réseau**.
1. Sélectionnez la première ENI que vous avez obtenue lors de la première étape. Choisissez le menu **Actions** en haut de l'écran, puis choisissez **Modifier les groupes de sécurité**. Assignez le nouveau groupe de sécurité à cette ENI. Répétez cette étape pour chacun des éléments ENIs que vous avez obtenus lors de la première étape.
**Note**
Les modifications que vous apportez au groupe de sécurité d'un cluster à l'aide de la console Amazon EC2 ne sont pas reflétées dans la console MSK sous **Paramètres réseau**.
1. Configurez les règles du nouveau groupe de sécurité pour garantir que vos clients ont accès aux agents. Pour de plus amples informations sur la définition de règles de groupe de sécurité, consultez [Ajout, Suppression et Mise à jour de règles](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules) dans le Guide de l'utilisateur Amazon VPC.
**Important**
Si vous modifiez le groupe de sécurité associé aux agents d'un cluster, puis que vous ajoutez de nouveaux agents à ce cluster, Amazon MSK associe les nouveaux agents au groupe de sécurité d'origine associé au cluster lors de sa création. Toutefois, pour qu'un cluster fonctionne correctement, tous ses agents doivent être associés au même groupe de sécurité. Par conséquent, si vous ajoutez de nouveaux courtiers après avoir modifié le groupe de sécurité, vous devez suivre à nouveau la procédure précédente et mettre à jour les ENIs nouveaux courtiers.
# Contrôlez l'accès aux ZooKeeper nœuds Apache de votre cluster Amazon MSK
Pour des raisons de sécurité, vous pouvez limiter l'accès aux ZooKeeper nœuds Apache qui font partie de votre cluster Amazon MSK. Pour limiter l'accès aux nœuds, vous pouvez leur attribuer un groupe de sécurité distinct. Vous pouvez ensuite décider qui a accès à ce groupe de sécurité.
**Important**
Cette section ne s'applique pas aux clusters exécutés en KRaft mode. Consultez [KRaft mode](metadata-management.md#kraft-intro).
**Topics**
+ [Pour placer vos ZooKeeper nœuds Apache dans un groupe de sécurité distinct](zookeeper-security-group.md)
+ [Utilisation de la sécurité TLS avec Apache ZooKeeper](zookeeper-security-tls.md)
# Pour placer vos ZooKeeper nœuds Apache dans un groupe de sécurité distinct
Pour limiter l'accès aux ZooKeeper nœuds Apache, vous pouvez leur attribuer un groupe de sécurité distinct. Vous pouvez choisir qui a accès à ce nouveau groupe de sécurité en définissant des règles de groupe de sécurité.
1. Obtenez la chaîne de ZooKeeper connexion Apache pour votre cluster. Pour savoir comment procéder, consultez [ZooKeeper mode](metadata-management.md#msk-get-connection-string). La chaîne de connexion contient les noms DNS de vos ZooKeeper nœuds Apache.
1. Utilisez un outil comme `host` ou `ping` pour convertir les noms DNS que vous avez obtenus à l'étape précédente en adresses IP. Enregistrez ces adresses IP car vous en aurez besoin plus tard dans cette procédure.
1. Connectez-vous à la console Amazon EC2 AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. Dans le panneau de navigation, sous **Network & Security (Réseau et sécurité)**, choisissez **Network Interfaces (Interfaces réseau)**.
1. Dans le champ de recherche au-dessus de la table des interfaces réseau, tapez le nom de votre cluster, puis appuyer sur retour. Cela limite le nombre d'interfaces réseau qui apparaissent dans la table aux interfaces associées à votre cluster.
1. Activez la case à cocher au début de la ligne qui correspond à la première interface réseau de la liste.
1. Dans le volet de détails au bas de la page, recherchez l'** IPv4 adresse IP privée principale**. Si cette adresse IP correspond à l'une des adresses IP que vous avez obtenues lors de la première étape de cette procédure, cela signifie que cette interface réseau est attribuée à un ZooKeeper nœud Apache qui fait partie de votre cluster. Sinon, désactivez la case à cocher en regard de cette interface réseau et sélectionnez l'interface réseau suivante dans la liste. L'ordre dans lequel vous sélectionnez les interfaces réseau n'a pas d'importance. Dans les étapes suivantes, vous allez effectuer les mêmes opérations sur toutes les interfaces réseau assignées aux ZooKeeper nœuds Apache, une par une.
1. Lorsque vous sélectionnez une interface réseau correspondant à un ZooKeeper nœud Apache, choisissez le menu **Actions** en haut de la page, puis choisissez **Modifier les groupes de sécurité**. Attribuez un nouveau groupe de sécurité à cette interface réseau. Pour de plus amples informations sur la création des groupes de sécurité, consultez [Création d'un groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#CreatingSecurityGroups) dans la documentation Amazon VPC.
1. Répétez l'étape précédente pour attribuer le même nouveau groupe de sécurité à toutes les interfaces réseau associées aux ZooKeeper nœuds Apache de votre cluster.
1. Vous pouvez désormais choisir qui a accès à ce nouveau groupe de sécurité. Pour de plus amples informations sur la définition de règles de groupe de sécurité, consultez [Ajout, Suppression et Mise à jour de règles](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules) dans la documentation Amazon VPC.
# Utilisation de la sécurité TLS avec Apache ZooKeeper
Vous pouvez utiliser la sécurité TLS pour le chiffrement en transit entre vos clients et vos ZooKeeper nœuds Apache. Pour implémenter la sécurité TLS avec vos ZooKeeper nœuds Apache, procédez comme suit :
+ Les clusters doivent utiliser Apache Kafka version 2.5.1 ou ultérieure pour utiliser la sécurité TLS avec Apache. ZooKeeper
+ Activez la sécurité TLS lorsque vous créez ou configurez votre cluster. Les clusters créés avec Apache Kafka version 2.5.1 ou ultérieure avec TLS activé utilisent automatiquement la sécurité TLS avec les points de terminaison Apache. ZooKeeper Pour plus d'informations sur la configuration de la sécurité TLS, consultez [Commencez avec le chiffrement Amazon MSK](msk-working-with-encryption.md).
+ Récupérez les ZooKeeper points de terminaison TLS Apache à l'aide de l'opération [DescribeCluster ](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster).
+ Créez un fichier ZooKeeper de configuration Apache à utiliser avec les [https://kafka.apache.org/documentation/#security_authz_cli](https://kafka.apache.org/documentation/#security_authz_cli)outils `kafka-configs.sh` et ou avec le ZooKeeper shell. Avec chaque outil, vous utilisez le `--zk-tls-config-file` paramètre pour spécifier votre ZooKeeper configuration Apache.
L'exemple suivant montre un fichier de ZooKeeper configuration Apache typique :
```
zookeeper.ssl.client.enable=true
zookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
zookeeper.ssl.keystore.location=kafka.jks
zookeeper.ssl.keystore.password=test1234
zookeeper.ssl.truststore.location=truststore.jks
zookeeper.ssl.truststore.password=test1234
```
+ Pour les autres commandes (telles que`kafka-topics`), vous devez utiliser la variable d'`KAFKA_OPTS`environnement pour configurer les ZooKeeper paramètres Apache. L'exemple suivant montre comment configurer la variable d'`KAFKA_OPTS`environnement pour transmettre les ZooKeeper paramètres Apache à d'autres commandes :
```
export KAFKA_OPTS="
-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
-Dzookeeper.client.secure=true
-Dzookeeper.ssl.trustStore.location=/home/ec2-user/kafka.client.truststore.jks
-Dzookeeper.ssl.trustStore.password=changeit"
```
Après avoir configuré la variable d'environnement `KAFKA_OPTS`, vous pouvez utiliser les commandes de l'interface de ligne de commande normalement. L'exemple suivant crée un sujet Apache Kafka en utilisant la ZooKeeper configuration Apache à partir de la variable d'`KAFKA_OPTS`environnement :
```
/bin/kafka-topics.sh --create --zookeeper ZooKeeperTLSConnectString --replication-factor 3 --partitions 1 --topic AWSKafkaTutorialTopic
```
**Note**
Les noms des paramètres que vous utilisez dans votre fichier de ZooKeeper configuration Apache et ceux que vous utilisez dans votre variable d'`KAFKA_OPTS`environnement ne sont pas cohérents. Faites attention aux noms que vous utilisez et aux paramètres de votre fichier de configuration et de votre variable d'environnement `KAFKA_OPTS`.
Pour plus d'informations sur l'accès à vos ZooKeeper nœuds Apache avec TLS, voir [KIP-515 : Permettre au client ZK d'utiliser](https://cwiki.apache.org/confluence/display/KAFKA/KIP-515%3A+Enable+ZK+client+to+use+the+new+TLS+supported+authentication) la nouvelle authentification prise en charge par TLS.
# Validation de conformité pour Amazon Managed Streaming for Apache Kafka
Des auditeurs tiers évaluent la sécurité et la conformité d'Amazon Managed Streaming for Apache Kafka dans le cadre de programmes de conformité AWS . Ceux-ci comprennent PCI et HIPAA BAA.
Pour obtenir la liste des AWS services concernés par des programmes de conformité spécifiques, consultez [Amazon Services inclus dans le champ d'application par programme de conformité](https://aws.amazon.com/compliance/services-in-scope/) . Pour des informations générales, voir Programmes de [AWS conformité Programmes AWS](https://aws.amazon.com/compliance/programs/) de .
Vous pouvez télécharger des rapports d'audit tiers à l'aide de AWS Artifact. Pour plus d'informations, voir [Téléchargement de rapports dans AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
Lorsque vous utilisez Amazon MSK, votre responsabilité en matière de conformité dépend de la sensibilité de vos données, des objectifs de conformité de votre entreprise et des lois et réglementations applicables. AWS fournit les ressources suivantes pour faciliter la mise en conformité :
+ [Guides démarrage rapide de la sécurité et de la conformité](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance). Ces guides de déploiement traitent des considérations architecturales et fournissent des étapes pour déployer des environnements de base axés sur la sécurité et la conformité sur AWS.
+ Livre blanc [sur l'architecture pour la sécurité et la conformité HIPAA — Ce livre blanc](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html) décrit comment les entreprises peuvent créer des applications conformes à la loi HIPAA. AWS
+ AWS Ressources de [https://aws.amazon.com/compliance/resources/](https://aws.amazon.com/compliance/resources/) de conformité — Cette collection de classeurs et de guides peut s'appliquer à votre secteur d'activité et à votre région.
+ [Évaluation des ressources à l'aide des règles](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) du *guide du AWS Config développeur* : le AWS Config service évalue dans quelle mesure les configurations de vos ressources sont conformes aux pratiques internes, aux directives du secteur et aux réglementations.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— Ce AWS service fournit une vue complète de l'état de votre sécurité interne, AWS ce qui vous permet de vérifier votre conformité aux normes et aux meilleures pratiques du secteur de la sécurité.
# Résilience dans Amazon Managed Streaming for Apache Kafka
L'infrastructure AWS mondiale est construite autour des AWS régions et des zones de disponibilité. AWS Les régions fournissent plusieurs zones de disponibilité physiquement séparées et isolées, connectées par un réseau à faible latence, à haut débit et hautement redondant. Avec les zones de disponibilité, vous pouvez concevoir et exploiter des applications et des bases de données qui basculent automatiquement d’une zone à l’autre sans interruption. Les zones de disponibilité sont davantage disponibles, tolérantes aux pannes et ont une plus grande capacité de mise à l’échelle que les infrastructures traditionnelles à un ou plusieurs centres de données.
Pour plus d'informations sur AWS les régions et les zones de disponibilité, consultez la section [Infrastructure AWS mondiale](https://aws.amazon.com/about-aws/global-infrastructure/).
# Sécurité de l'infrastructure dans Amazon Managed Streaming for Apache Kafka
En tant que service géré, Amazon Managed Streaming for Apache Kafka est protégé par les procédures de sécurité du réseau AWS mondial décrites dans le livre blanc [Amazon Web Services : Overview of Security Processes](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf).
Vous utilisez des appels d'API AWS publiés pour accéder à Amazon MSK via le réseau. Les clients doivent supporter le protocole TLS (Sécurité de la couche transport) 1.0 ou une version ultérieure. Nous recommandons TLS 1.2 ou version ultérieure. Les clients doivent aussi prendre en charge les suites de chiffrement PFS (Perfect Forward Secrecy) comme Ephemeral Diffie-Hellman (DHE) ou Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). La plupart des systèmes modernes tels que Java 7 et les versions ultérieures prennent en charge ces modes.
En outre, les demandes doivent être signées à l’aide d’un ID de clé d’accès et d’une clé d’accès secrète associée à un principal IAM. Vous pouvez également utiliser [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) pour générer des informations d’identification de sécurité temporaires et signer les demandes.