Amazon KMS key management
Amazon Aurora automatically integrates with Amazon Key Management Service (Amazon KMS) for key management. Amazon Aurora uses envelope encryption. For more information about envelope encryption, see Envelope encryption in the Amazon Key Management Service Developer Guide.
You can use two types of Amazon KMS keys to encrypt your DB clusters.
If you want full control over a KMS key, you must create a customer managed key. For more information about customer managed keys, see Customer managed keys in the Amazon Key Management Service Developer Guide.
You can't share a snapshot that has been encrypted using the Amazon managed key of the Amazon account that shared the snapshot.
Amazon managed keys are KMS keys in your account that are created, managed, and used on your behalf by an Amazon service that is integrated with Amazon KMS. By default, the RDS Amazon managed key (
aws/rds
) is used for encryption. You can't manage, rotate, or delete the RDS Amazon managed key. For more information about Amazon managed keys, see Amazon managed keys in the Amazon Key Management Service Developer Guide.
To manage KMS keys used for Amazon Aurora encrypted DB clusters, use the Amazon Key Management Service
(Amazon KMS) in the Amazon KMS console
If you turn off or revoke permissions to a KMS key used by an RDS database, RDS puts your database into a terminal state when access to the KMS key is required. This change could be immediate, or deferred, depending on the use case that required access to the KMS key. In this state, the DB cluster is no longer available, and the current state of the database can't be recovered. To restore the DB cluster, you must re-enable access to the KMS key for RDS, and then restore the DB cluster from the latest available backup.
Authorizing use of a customer managed key
When Aurora uses a customer managed key in cryptographic operations, it acts on behalf of the user who is creating or changing the Aurora resource.
To create an Aurora resource using a customer managed key, a user must have permissions to call the following operations on the customer managed key:
-
kms:CreateGrant
-
kms:DescribeKey
You can specify these required permissions in a key policy, or in an IAM policy if the key policy allows it.
You can make the IAM policy stricter in various ways. For example, if you want
to allow the customer managed key to be used only for requests that originate in
Aurora, you can use the kms:ViaService condition key with the
rds.
value. Also, you can use the keys or values in the Amazon RDS encryption context as a
condition for using the customer managed key for encryption.<region>
.amazonaws.com
For more information, see Allowing users in other accounts to use a KMS key in the Amazon Key Management Service Developer Guide and Key policies in Amazon KMS.
Amazon RDS encryption context
When Aurora uses your KMS key, or when Amazon EBS uses the KMS key on behalf of Aurora, the service
specifies an encryption context. The encryption context
is additional authenticated
data (AAD) that Amazon KMS uses to ensure data integrity. When an encryption context is
specified for an encryption operation, the service must specify the same encryption context
for the decryption operation. Otherwise, decryption fails. The encryption context is also
written to your Amazon CloudTrail
At minimum, Aurora always uses the DB instance ID for the encryption context, as in the following JSON-formatted example:
{ "aws:rds:db-id": "db-CQYSMDPBRZ7BPMH7Y3RTDG5QY" }
This encryption context can help you identify the DB instance for which your KMS key was used.
When your KMS key is used for a specific DB instance and a specific Amazon EBS volume, both the DB instance ID and the Amazon EBS volume ID are used for the encryption context, as in the following JSON-formatted example:
{ "aws:rds:db-id": "db-BRG7VYS3SVIFQW7234EJQOM5RQ", "aws:ebs:id": "vol-ad8c6542" }