Managing secrets and resource policies
When you configure a third-party speech provider, you will need to create a secret in Secrets Manager that contains the speech provider's API key. Creating the secret is a two step process:
-
Create the secret containin the API key. For instructions, see Create an AWS Secrets Manager secret.
-
Configure the necessary permissions:
-
Attach a resource-based policy to the secret.
-
Attach a resource-based policy to the KMS key (not the API key) associated with the secret. The KMS key protects the API key in the secret.
These policies allow Amazon Connect to access to the API key within the secret. Note that you cannot use the default
aws/secretsmanagerKMS key; you will have to create a new key or use an existing customer-managed key. For more information about how KMS keys secure secrets, see Secret encryption and decryption in Secrets Manager. -
Make sure that the resource-based policy for the secret includes the
aws:SourceAccount and aws:SourceArn confused deputy conditions
(see The confused
deputy problem) and that the resource-based policy for the KMS key includes the
kms:EncryptionContext:SecretARN condition. This will ensure that Amazon Connect can
only access your API key secret in context of a single specific instance, and can only access
your KMS key in context of both that instance and the specific secret.
Example of a resource-based policy for Secrets Manager secrets
The following is an example of a resource-based policy that you can attach to your secret.
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "connect.amazonaws.com" ] }, "Action": "secretsmanager:GetSecretValue", "Resource": "*", "Condition": { "ArnLike": { "aws:sourceArn": "///the ARN of your Amazon Connect instance///" }, "StringEquals": { "aws:sourceAccount": "///Your account ID///" } } } ] }
Example of a resource-based policy for AWS KMS keys
The following is an example of a resource-based policy that you can attach to your KMS key.
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "connect.amazonaws.com" ] }, "Action": "kms:Decrypt", "Resource": "*", "Condition": { "ArnLike": { "aws:sourceArn": "///the ARN of your Amazon Connect instance///" }, "StringEquals": { "aws:sourceAccount": "///Your account ID///", "kms:EncryptionContext:SecretARN": "///the ARN of your secrets manager secret///" } } } ] }
Attaching a resource-based policy to your Secrets Manager secret
To attach a resource-based policy to your secret, go to the Secrets Manager console
within the AWS Management Console, navigate to your secret, choose Edit
Permissions or Resource Permissions and then add or
modify the resource policy directly on the page so that it looks similar to the example. You can also attach
the resource policy through the AWS CLI's put-resource-policy command, or
programmatically using the PutResourcePolicy API operation.
Attaching a resource-based policy to your KMS key
To attach a resource-based policy to your KMS key, go to the AWS Key Management Service console within
the AWS Management Console, navigate to your KMS key and edit your key policy to look like the example. You can also update the key
through the AWS CLI's put-key-policy command, or programmatically using the
PutKeyPolicy API operation.
Rotating API keys
We recommend rotating API keys at least every 90 days to minimize the risk of compromise, and to maintain a well-practiced key rotation process for emergency situations.
To rotate an API key, you must rotate the secret in which it is contained. See Rotate Secrets Manager secrets in the Secrets Manager User Guide for more information on how to rotate secrets. When you rotate an API key, it is recommended that you wait for the previous key's usage to drop to zero before revoking the old API key to ensure that ongoing requests are not impacted.