View a markdown version of this page

Autorisations SER supplémentaires pour SASL/SCRAM les clés mTL et gérées par le client SASL/OAUTHBEARER - Amazon Managed Streaming for Apache Kafka

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.

Autorisations SER supplémentaires pour SASL/SCRAM les clés mTL et gérées par le client SASL/OAUTHBEARER

La politique AWSMSKReplicatorExecutionRole gérée couvre les autorisations de cluster, de sujet et de groupe de consommateurs pour l'authentification IAM. Lorsque vous effectuez une réplication vers ou depuis un cluster qui utilise SASL/SCRAM l'authentification mTLS ou SASL/OAUTHBEARER (OAuth) (par exemple, lors d'une migration depuis un cluster Apache Kafka autogéré), ou lorsque votre secret est chiffré à l'aide d'une clé gérée par le client (CMK), vous devez associer des autorisations en ligne supplémentaires au rôle d'exécution du service.

Utilisez les extraits ci-dessous en plus de la politique gérée. Choisissez le scénario qui correspond à votre configuration.

SASL/SCRAM secret (avec ou sans secret TLS root CA)

Accorde au SER l'autorisation de lire les informations d'identification SCRAM et (éventuellement) le certificat CA privé provenant de AWS Secrets Manager. Remplacez-le <saslSecretArn> par votre ARN secret SCRAM et <privateCaCertSecretArn> par le secret contenant le certificat CA (omettez le second ARN si vous utilisez un certificat approuvé publiquement).

{ "Version": "2012-10-17", "Statement": [ { "Sid": "SecretsManagerPermissions", "Effect": "Allow", "Action": [ "secretsmanager:GetResourcePolicy", "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret", "secretsmanager:ListSecretVersionIds" ], "Resource": [ "<saslSecretArn>", "<privateCaCertSecretArn>" ] } ] }
Secret mTLS (avec ou sans secret CA racine TLS)

Accorde au SER l'autorisation de lire le certificat client et la clé privée depuis AWS Secrets Manager. Remplacez-le <mtlsSecretArn> par l'ARN de votre secret mTLS et <privateCaCertSecretArn> par le secret contenant le certificat CA du serveur (omettez le second ARN si vous utilisez un certificat approuvé publiquement).

{ "Version": "2012-10-17", "Statement": [ { "Sid": "SecretsManagerPermissions", "Effect": "Allow", "Action": [ "secretsmanager:GetResourcePolicy", "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret", "secretsmanager:ListSecretVersionIds" ], "Resource": [ "<mtlsSecretArn>", "<privateCaCertSecretArn>" ] } ] }
SASL/OAUTHBEARER

Les autorisations dont le SER a besoin SASL/OAUTHBEARER dépendent du mécanisme :

  • Informations d'identification du client  : accordez un accès en AWS Secrets Manager lecture au secret qui contient client_id etclient_secret.

  • Assertion des informations d'identification du porteur et du client IAM JWT  : octroyez sts:GetWebIdentityToken pour que le SER puisse obtenir un JWT signé pour sa propre identité. AWS Accordez également l'accès en AWS Secrets Manager lecture si vous fournissez un secret facultatif.

Si votre IDP utilise une autorité de certification privée, accordez également un accès en AWS Secrets Manager lecture au secret contenant le certificat d'autorité de certification auquel vous faites référence. tokenEndpointTlsCertificateArn L'exemple suivant accorde les deux. <oauthSecretArn>Remplacez-le par votre ARN secret, <idpCaCertSecretArn> par l'ARN secret du certificat CA et <accountID> par votre Compte AWS identifiant. Omettez complètement l'SecretsManagerPermissionsinstruction si vous utilisez le support IAM JWT ou le mécanisme d'assertion des informations d'identification du client sans secret et que votre IDP utilise un certificat approuvé publiquement ; omettez l'StsPermissionsinstruction si vous utilisez le mécanisme des informations d'identification du client.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "SecretsManagerPermissions", "Effect": "Allow", "Action": [ "secretsmanager:GetResourcePolicy", "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret", "secretsmanager:ListSecretVersionIds" ], "Resource": [ "<oauthSecretArn>", "<idpCaCertSecretArn>" ] }, { "Sid": "StsPermissions", "Effect": "Allow", "Action": "sts:GetWebIdentityToken", "Resource": "arn:aws:sts::<accountID>:self" } ] }
Chiffrement secret à l'aide d'une clé gérée par le client

Si le secret est chiffré à l'aide d'une clé CMK plutôt que de la clé AWS gérée, accordez également kms:Decrypt la CMK. <customerManagedKeyArn>Remplacez-le par l'ARN CMK.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "SecretsManagerPermissions", "Effect": "Allow", "Action": [ "secretsmanager:GetResourcePolicy", "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret", "secretsmanager:ListSecretVersionIds" ], "Resource": [ "<secretArn>", "<privateCaCertSecretArn>" ] }, { "Sid": "KmsPermissions", "Effect": "Allow", "Action": "kms:Decrypt", "Resource": [ "<customerManagedKeyArn>" ] } ] }
Note

Si vous préférez une portée plus large conformément aux autorisations du fournisseur de configuration MSK Connect, vous pouvez utiliser arn:aws:secretsmanager:<region>:<accountID>:secret:AmazonMSK_* comme modèle de ressource au lieu des ARN secrets individuels.