View a markdown version of this page

Additional SER permissions for SASL/SCRAM, mTLS, SASL/OAUTHBEARER, and customer managed keys - Amazon Managed Streaming for Apache Kafka
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Additional SER permissions for SASL/SCRAM, mTLS, SASL/OAUTHBEARER, and customer managed keys

The AWSMSKReplicatorExecutionRole managed policy covers cluster, topic, and consumer group permissions for IAM auth. When you replicate to or from a cluster that uses SASL/SCRAM, mTLS, or SASL/OAUTHBEARER (OAuth) authentication (for example, when migrating from a self-managed Apache Kafka cluster), or when your secret is encrypted with a customer managed key (CMK), you need to attach additional inline permissions to the service execution role.

Use the snippets below in addition to the managed policy. Pick the scenario that matches your setup.

SASL/SCRAM secret (with or without TLS root CA secret)

Grants the SER permission to read SCRAM credentials and (optionally) the private CA certificate from Amazon Secrets Manager. Replace <saslSecretArn> with your SCRAM secret ARN and <privateCaCertSecretArn> with the secret holding the CA certificate (omit the second ARN if you use a publicly trusted certificate).

{ "Version": "2012-10-17", "Statement": [ { "Sid": "SecretsManagerPermissions", "Effect": "Allow", "Action": [ "secretsmanager:GetResourcePolicy", "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret", "secretsmanager:ListSecretVersionIds" ], "Resource": [ "<saslSecretArn>", "<privateCaCertSecretArn>" ] } ] }
mTLS secret (with or without TLS root CA secret)

Grants the SER permission to read the client certificate and private key from Amazon Secrets Manager. Replace <mtlsSecretArn> with the ARN of your mTLS secret and <privateCaCertSecretArn> with the secret holding the server CA certificate (omit the second ARN if you use a publicly trusted certificate).

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

The permissions the SER needs for SASL/OAUTHBEARER depend on the mechanism:

  • Client credentials — Grant Amazon Secrets Manager read access to the secret that holds client_id and client_secret.

  • IAM JWT bearer and client credentials assertion — Grant sts:GetWebIdentityToken so the SER can obtain a signed JWT for its own Amazon identity. Also grant Amazon Secrets Manager read access if you supply an optional secret.

If your IDP uses a private CA, also grant Amazon Secrets Manager read access to the secret that holds the CA certificate you reference in tokenEndpointTlsCertificateArn. The following example grants both. Replace <oauthSecretArn> with your secret ARN, <idpCaCertSecretArn> with the CA certificate secret ARN, and <accountID> with your Amazon Web Services account ID. Omit the SecretsManagerPermissions statement entirely if you use the IAM JWT bearer or client credentials assertion mechanism without a secret and your IDP uses a publicly trusted certificate; omit the StsPermissions statement if you use the client credentials mechanism.

{ "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" } ] }
Secret encrypted with a customer managed key

If the secret is encrypted with a CMK rather than the Amazon-managed key, also grant kms:Decrypt on the CMK. Replace <customerManagedKeyArn> with the CMK ARN.

{ "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

If you prefer wider scoping consistent with the MSK Connect configuration provider permissions, you can use arn:aws:secretsmanager:<region>:<accountID>:secret:AmazonMSK_* as the resource pattern instead of individual secret ARNs.