# Data encryption
Amazon Bedrock uses encryption to protect data at rest and data in transit.
**Encryption in transit**
Within AWS, all inter-network data in transit supports TLS 1.2 encryption.
Requests to the Amazon Bedrock API and console are made over a secure (SSL) connection. You pass AWS Identity and Access Management (IAM) roles to Amazon Bedrock to provide permissions to access resources on your behalf for training and deployment.
**Encryption at rest**
Amazon Bedrock provides [Encryption of custom models](encryption-custom-job.md) at rest.
## Key management
Use the AWS Key Management Service to manage the keys that you use to encrypt your resources. For more information, see [AWS Key Management Service concepts](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys). You can encrypt the following resources with a KMS key.
+ Through Amazon Bedrock
+ Model customization jobs and their output custom models – During job creation in the console or by specifying the `customModelKmsKeyId` field in the [CreateModelCustomizationJob](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateModelCustomizationJob.html) API call.
+ Agents – During agent creation in the console or by specifying the `customerEncryptionKeyArn` field in the [CreateAgent](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_CreateAgent.html) API call.
+ Data source ingestion jobs for knowledge bases – During knowledge base creation in the console or by specifying the `kmsKeyArn` field in the [CreateDataSource](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_CreateDataSource.html) or [UpdateDataSource](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_UpdateDataSource.html) API call.
+ Vector stores in Amazon OpenSearch Service – During vector store creation. For more information, see [Creating, listing, and deleting Amazon OpenSearch Service collections](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-manage.html) and [Encryption of data at rest for Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/encryption-at-rest.html).
+ Model evaluations jobs – When you create a model evaluation job in console or by specify a key ARN in ` customerEncryptionKeyId` in the [CreateEvaluationJob ](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateEvaluationJob.html) API call.
+ Through Amazon S3 – For more information, see [Using server-side encryption with AWS KMS keys (SSE-KMS).](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html)
+ Training, validation, and output data for model customization
+ Data sources for knowledge bases
+ Through AWS Secrets Manager – For more information, see [Secret encryption and decryption in AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html)
+ Vector stores for third-party models
After you encrypt a resource, you can find the ARN of the KMS key by selecting a resource and viewing its **Details** in the console or by using the following `Get` API calls.
+ [GetModelCustomizationJob](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_GetModelCustomizationJob.html)
+ [GetAgent](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_GetAgent.html)
+ [GetIngestionJob](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_GetIngestionJob.html)
# Encryption of custom models
Amazon Bedrock uses your training data with the [CreateModelCustomizationJob](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateModelCustomizationJob.html) action, or with the [console](model-customization-submit.md), to create a custom model which is a fine tuned version of an Amazon Bedrock foundational model. Your custom models are managed and stored by AWS.
Amazon Bedrock uses the fine tuning data you provide only for fine tuning an Amazon Bedrock foundation model. Amazon Bedrock doesn't use fine tuning data for any other purpose. Your training data isn't used to train the base Titan models or distributed to third parties. Other usage data, such as usage timestamps, logged account IDs, and other information logged by the service, is also not used to train the models.
None of the training or validation data you provide for fine tuning is stored by Amazon Bedrock, once the fine tuning job completes.
Note that fine-tuned models can replay some of the fine tuning data while generating completions. If your app should not expose fine tuning data in any form, then you should first filter out confidential data from your training data. If you already created a customized model using confidential data by mistake, you can delete that custom model, filter out confidential information from the training data, and then create a new model.
For encrypting custom models (including copied models), Amazon Bedrock offers you two options:
1. **AWS owned keys** – By default, Amazon Bedrock encrypts custom models with AWS owned keys. You can't view, manage, or use AWS owned keys, or audit their use. However, you don't have to take any action or change any programs to protect the keys that encrypt your data. For more information, see [AWS owned keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) in the *AWS Key Management Service Developer Guide*.
1. **Customer managed keys** – You can choose to encrypt custom models with customer managed keys that you manage yourself. For more information about AWS KMS keys, see [Customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in the *AWS Key Management Service Developer Guide*.
**Note**
Amazon Bedrock automatically enables encryption at rest using AWS owned keys at no charge. If you use a customer managed key, AWS KMS charges apply. For more information about pricing, see [AWS Key Management Service pricing](https://aws.amazon.com/kms/pricing/).
For more information about AWS KMS, see the [AWS Key Management Service Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/).
**Topics**
+ [How Amazon Bedrock uses grants in AWS KMS](#encryption-br-grants)
+ [Understand how to create a customer managed key and how to attach a key policy to it](#encryption-key-policy)
+ [Permissions and key policies for custom and copied models](#encryption-cm-statements)
+ [Monitor your encryption keys for the Amazon Bedrock service](#encryption-monitor-key)
+ [Encryption of training, validation, and output data](#encryption-custom-job-data)
## How Amazon Bedrock uses grants in AWS KMS
If you specify a customer managed key to encrypt a custom model for a model customization or model copy job, Amazon Bedrock creates a **primary** KMS [grant](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) associated with the custom model on your behalf by sending a [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) request to AWS KMS. This grant allows Amazon Bedrock to access and use your customer managed key. Grants in AWS KMS are used to give Amazon Bedrock access to a KMS key in a customer’s account.
Amazon Bedrock requires the primary grant to use your customer managed key for the following internal operations:
+ Send [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) requests to AWS KMS to verify that the symmetric customer managed KMS key ID you entered when creating the job is valid.
+ Send [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) and [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) requests to AWS KMS to generate data keys encrypted by your customer managed key and decrypt the encrypted data keys so that they can be used to encrypt the model artifacts.
+ Send [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) requests to AWS KMS to create scoped down secondary grants with a subset of the above operations (`DescribeKey`, `GenerateDataKey`, `Decrypt`), for the asynchronous execution of model customization, model copy, or Provisioned Throughput creation.
+ Amazon Bedrock specifies a retiring principal during the creation of grants, so the service can send a [RetireGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_RetireGrant.html) request.
You have full access to your customer managed AWS KMS key. You can revoke access to the grant by following the steps at [Retiring and revoking grants](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#grant-delete) in the [AWS Key Management Service Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/) or remove the service’s access to your customer managed key at any time by modifying the [key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). If you do so, Amazon Bedrock won’t be able to access the custom model encrypted by your key.
### Life cycle of primary and secondary grants for custom models
+ **Primary grants** have a long lifespan and remain active as long as the associated custom models are still in use. When a custom model is deleted, the corresponding primary grant is automatically retired.
+ **Secondary grants** are short-lived. They are automatically retired as soon as the operation that Amazon Bedrock performs on behalf of the customers is completed. For example, once a model copy job is finished, the secondary grant that allowed Amazon Bedrock to encrypt the copied custom model will be retired immediately.
## Understand how to create a customer managed key and how to attach a key policy to it
To encrypt an AWS resource with a key that you create and manage, you perform the following general steps:
1. (Prerequisite) Ensure that your IAM role has permissions for the [CreateKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateKey.html) action.
1. Follow the steps at [Creating keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) to create a customer managed key by using the AWS KMS console or the [CreateKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateKey.html) operation.
1. Creation of the key returns an `Arn` for the key that you can use for operations that require using the key (for example, when [submitting a model customization job](model-customization-submit.md) or [running model inference](inference-invoke.md)).
1. Create and attach a key policy to the key with the required permissions. To create a key policy, follow the steps at [Creating a key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-overview.html) in the AWS Key Management Service Developer Guide.
## Permissions and key policies for custom and copied models
After you create a KMS key, you attach a key policy to it. Key policies are [resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) that you attach to your customer managed key to control access to it. Every customer managed key must have exactly one key policy, which contains statements that determine who can use the key and how they can use it. You can specify a key policy when you create your customer managed key. You can modify the key policy at any time, but there might be a brief delay before the change becomes available throughout AWS KMS. For more information, see [Managing access to customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html#managing-access) in the [AWS Key Management Service Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/).
The following KMS [actions](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html#awskeymanagementservice-actions-as-permissions) are used for keys that encrypt custom and copied models:
1. [kms:CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) – Creates a grant for a customer managed key by allowing the Amazon Bedrock service principal access to the specified KMS key through [grant operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations). For more information about grants, see [Grants in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) in the [AWS Key Management Service Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/).
**Note**
Amazon Bedrock also sets up a retiring principal and automatically retires the grant after it is no longer required.
1. [kms:DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) – Provides the customer managed key details to allow Amazon Bedrock to validate the key.
1. [kms:GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) – Provides the customer managed key details to allow Amazon Bedrock to validate user access. Amazon Bedrock stores generated ciphertext alongside the custom model to be used as an additional validation check against custom model users.
1. [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) – Decrypts the stored ciphertext to validate that the role has proper access to the KMS key that encrypts the custom model.
As a best security practice, we recommend that you include the [kms:ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/conditions-kms.html#conditions-kms-via-service) condition key to limit access to the key to the Amazon Bedrock service.
Although you can only attach one key policy to a key, you can attach multiple statements to the key policy by adding staements to the list in the `Statement` field of the policy.
The following statements are relevant to encrypting custom and copied models:
### Encrypt a model
To use your customer managed key to encrypt a custom or copied model, include the following statement in a key policy to allow encryption of a model. In the `Principal` field, add accounts that you want to allow to encrypt and decrypt the key to the list that the `AWS` subfield maps to. If you use the `kms:ViaService` condition key, you can add a line for each Region, or use *\$1* in place of *\$1\$1region\$1* to allow all Regions that support Amazon Bedrock.
```
{
"Sid": "PermissionsEncryptDecryptModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::${account-id}:role/${role}"
]
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.${region}.amazonaws.com"
]
}
}
}
```
### Allow access to an encrypted model
To allow access to a model that has been encrypted with a KMS key, include the following statement in a key policy to allow decryption of the key. In the `Principal` field, add accounts that you want to allow to decrypt the key to the list that the `AWS` subfield maps to. If you use the `kms:ViaService` condition key, you can add a line for each Region, or use *\$1* in place of *\$1\$1region\$1* to allow all Regions that support Amazon Bedrock.
```
{
"Sid": "PermissionsDecryptModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::${account-id}:role/${role}"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.${region}.amazonaws.com"
]
}
}
}
```
To learn about the key policies that you need to create, expand the section that corresponds to your use case:
### Set up key permissions for encrypting custom models
If you plan to encrypt a model that you customize with a KMS key, the key policy for the key will depend on your use case. Expand the section that corresponds to your use case:
#### The roles that will customize the model and the roles that will invoke the model are the same
If the roles that will invoke the custom model are the same as the roles that will customize the model, you only need the statement from [Encrypt a model](#encryption-key-policy-encrypt). In the `Principal` field in the following policy template, add accounts that you want to allow to customize and invoke the custom model to the list that the `AWS` subfield maps to.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "PermissionsCustomModelKey",
"Statement": [
{
"Sid": "PermissionsEncryptCustomModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Role"
]
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
#### The roles that will customize the model and the roles that will invoke the model are different
If the roles that will invoke the custom model are different from the role that will customize the model, you need both the statement from [Encrypt a model](#encryption-key-policy-encrypt) and [Allow access to an encrypted model](#encryption-key-policy-decrypt). Modify the statements in the following policy template as follows:
1. The first statement allows encryption and decryption of the key. In the `Principal` field, add accounts that you want to allow to customize the custom model to the list that the `AWS` subfield maps to.
1. The second statement allows only decryption of the key. In the `Principal` field, add accounts that you want to only allow to invoke the custom model to the list that the `AWS` subfield maps to.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "PermissionsCustomModelKey",
"Statement": [
{
"Sid": "PermissionsEncryptCustomModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Role"
]
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
},
{
"Sid": "PermissionsDecryptModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Role"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
### Set up key permissions for copying custom models
When you copy a model that you own or that has been shared with you, you might have to manage up to two key policies:
#### Key policy for key that will encrypt a copied model
If you plan to use a KMS key to encrypt a copied model, the key policy for the key will depend on your use case. Expand the section that corresponds to your use case:
##### The roles that will copy the model and the roles that will invoke the model are the same
If the roles that will invoke the copied model are the same as the roles that will create the model copy, you only need the statement from [Encrypt a model](#encryption-key-policy-encrypt). In the `Principal` field in the following policy template, add accounts that you want to allow to copy and invoke the copied model to the list that the `AWS` subfield maps to:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "PermissionsCopiedModelKey",
"Statement": [
{
"Sid": "PermissionsEncryptCopiedModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Role"
]
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
##### The roles that will copy the model and the roles that will invoke the model are different
If the roles that will invoke the copied model are different from the role that will create the model copy, you need both the statement from [Encrypt a model](#encryption-key-policy-encrypt) and [Allow access to an encrypted model](#encryption-key-policy-decrypt). Modify the statements in the following policy template as follows:
1. The first statement allows encryption and decryption of the key. In the `Principal` field, add accounts that you want to allow to create the copied model to the list that the `AWS` subfield maps to.
1. The second statement allows only decryption of the key. In the `Principal` field, add accounts that you want to only allow to invoke the copied model to the list that the `AWS` subfield maps to.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "PermissionsCopiedModelKey",
"Statement": [
{
"Sid": "PermissionsEncryptCopiedModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Role"
]
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
},
{
"Sid": "PermissionsDecryptCopiedModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Role"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
#### Key policy for key that encrypts the source model to be copied
If the source model that you will copy is encrypted with a KMS key, attach the statement from [Allow access to an encrypted model](#encryption-key-policy-decrypt) to the key policy for the key that encrypts the source model. This stamtement allows the model copy role to decrypt the key that encrypts the source model. In the `Principal` field in the following policy template, add accounts that you want to allow to copy the source model to the list that the `AWS` subfield maps to:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "PermissionsSourceModelKey",
"Statement": [
{
"Sid": "PermissionsDecryptModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Role"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
## Monitor your encryption keys for the Amazon Bedrock service
When you use an AWS KMS customer managed key with your Amazon Bedrock resources, you can use [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) or [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) to track requests that Amazon Bedrock sends to AWS KMS.
The following is an example AWS CloudTrail event for [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) to monitor KMS operations called by Amazon Bedrock to create a primary grant:
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAIGDTESTANDEXAMPLE:SampleUser01",
"arn": "arn:aws:sts::111122223333:assumed-role/RoleForModelCopy/SampleUser01",
"accountId": "111122223333",
"accessKeyId": "EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAIGDTESTANDEXAMPLE",
"arn": "arn:aws:iam::111122223333:role/RoleForModelCopy",
"accountId": "111122223333",
"userName": "RoleForModelCopy"
},
"attributes": {
"creationDate": "2024-05-07T21:46:28Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "bedrock.amazonaws.com"
},
"eventTime": "2024-05-07T21:49:44Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-east-1",
"sourceIPAddress": "bedrock.amazonaws.com",
"userAgent": "bedrock.amazonaws.com",
"requestParameters": {
"granteePrincipal": "bedrock.amazonaws.com",
"retiringPrincipal": "bedrock.amazonaws.com",
"keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE",
"operations": [
"Decrypt",
"CreateGrant",
"GenerateDataKey",
"DescribeKey"
]
},
"responseElements": {
"grantId": "0ab0ac0d0b000f00ea00cc0a0e00fc00bce000c000f0000000c0bc0a0000aaafSAMPLE",
"keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE"
},
"requestID": "ff000af-00eb-00ce-0e00-ea000fb0fba0SAMPLE",
"eventID": "ff000af-00eb-00ce-0e00-ea000fb0fba0SAMPLE",
"readOnly": false,
"resources": [
{
"accountId": "111122223333",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111122223333",
"eventCategory": "Management"
}
```
## Encryption of training, validation, and output data
When you use Amazon Bedrock to run a model customization job, you store the input files in your Amazon S3 bucket. When the job completes, Amazon Bedrock stores the output metrics files in the S3 bucket that you specifed when creating the job and the resulting custom model artifacts in an S3 bucket controlled by AWS.
The output files are encrypted with the encryption configurations of the S3 bucket. These are encrypted either with [SSE-S3 server-side encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html) or with [AWS KMS SSE-KMS encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html), depending on how you set up the S3 bucket.
# Encryption of imported custom models
Amazon Bedrock supports creating custom models through two methods that both use the same encryption approach. Your custom models are managed and stored by AWS:
+ **Custom model import jobs** — For importing customized open-source foundation models (such as Mistral AI or Llama models).
+ **Create custom model** — For importing Amazon Nova models that you customized in SageMaker AI.
For encryption of your custom models, Amazon Bedrock provides the following options:
+ **AWS owned keys** – By default, Amazon Bedrock encrypts imported custom models with AWS owned keys. You can't view, manage, or use AWS owned keys, or audit their use. However, you don't have to take any action or change any programs to protect the keys that encrypt your data. For more information, see [AWS owned keys](https://docs.aws.amazon.com//kms/latest/developerguide/concepts.html#aws-owned-cmk) in the *AWS Key Management Service Developer Guide*.
+ **Customer managed keys (CMK)** – You can choose to add a second layer of encryption over the existing AWS owned encryption keys by choosing a customer managed key(CMK). You create, own, and manage your customer managed keys.
Because you have full control of this layer of encryption, in it you can perform the following tasks:
+ Establish and maintain key policies
+ Establish and maintain IAM policies and grants
+ Enable and disable key policies
+ Rotate key cryptographic material
+ Add tags
+ Create key aliases
+ Schedule keys for deletion
For more information, see [customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in the *AWS Key Management Service Developer Guide*.
**Note**
For all the custom models that you import, Amazon Bedrock automatically enables encryption at rest using AWS owned keys to protect customer data at no charge. If you use a customer managed key, AWS KMS charges apply. For more information about pricing, see [AWS Key Management Service Pricing.](https://docs.aws.amazon.com/).
## How Amazon Bedrock uses grants in AWS KMS
If you specify a customer managed key to encrypt the imported model. Amazon Bedrock creates a **primary** AWS KMS [grant](https://docs.aws.amazon.com/) associated with the imported model on your behalf by sending a [CreateGrant](https://docs.aws.amazon.com//kms/latest/APIReference/API_CreateGrant.html) request to AWS KMS. This grant allows Amazon Bedrock to access and use your customer managed key. Grants in AWS KMS are used to give Amazon Bedrock access to a KMS key in a customer’s account.
Amazon Bedrock requires the primary grant to use your customer managed key for the following internal operations:
+ Send [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) requests to AWS KMS to verify that the symmetric customer managed KMS key ID you entered when creating the job is valid.
+ Send [GenerateDataKey](https://docs.aws.amazon.com//kms/latest/APIReference/API_GenerateDataKey.html) and [Decrypt](https://docs.aws.amazon.com//kms/latest/APIReference/API_Decrypt.html) requests to AWS KMS to generate data keys encrypted by your customer managed key and decrypt the encrypted data keys so that they can be used to encrypt the model artifacts.
+ Send [CreateGrant](https://docs.aws.amazon.com//kms/latest/APIReference/API_CreateGrant.html) requests to AWS KMS to create scoped down secondary grants with a subset of the above operations (`DescribeKey`, `GenerateDataKey`, `Decrypt`), for the asynchronous execution of model import and for on-demand inference.
+ Amazon Bedrock specifies a retiring principal during the creation of grants, so the service can send a [RetireGrant](https://docs.aws.amazon.com//kms/latest/APIReference/API_RetireGrant.html) request.
You have full access to your customer managed AWS KMS key. You can revoke access to the grant by following the steps at [Retiring and revoking grants](https://docs.aws.amazon.com//kms/latest/developerguide/grant-manage.html#grant-delete) in the *AWS Key Management Service Developer Guide* or remove the service’s access to your customer managed key at any time by modifying the key policy. If you do so, Amazon Bedrock won’t be able to access the imported model encrypted by your key.
### Life cycle of primary and secondary grants for custom imported models
+ **Primary grants** have a long lifespan and remain active as long as the associated custom models are still in use. When a custom imported model is deleted, the corresponding primary grant is automatically retired.
+ **Secondary grants** are short-lived. They are automatically retired as soon as the operation that Amazon Bedrock performs on behalf of the customers is completed. For example, once a custom model import job is finished, the secondary grant that allowed Amazon Bedrock to encrypt the custom imported model will be retired immediately.
# Using customer managed key (CMK)
If you are planning to use customer managed key to encrypt your custom imported model, complete the following steps:
1. Create a customer managed key with the AWS Key Management Service.
1. Attach a [resource-based policy](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_identity-vs-resource.html) with permissions for the specified-roles to create and use custom imported models.
**Create a customer managed key**
First ensure that you have `CreateKey` permissions. Then follow the steps at [creating keys](https://docs.aws.amazon.com//kms/latest/developerguide/create-keys.html) to create a customer managed keys either in the AWS KMS console or the [CreateKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateKey.html) API operation. Make sure to create a symmetric encryption key.
Creation of the key returns an `Arn` for the key that you can use as the `importedModelKmsKeyId ` when importing a custom model with custom model import.
**Create a key policy and attach it to the customer managed key**
Key policies are [resource-based policy](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_identity-vs-resource.html) that you attach to your customer managed key to control access to it. Every customer managed key must have exactly one key policy, which contains statements that determine who can use the key and how they can use it. You can specify a key policy when you create your customer managed key. You can modify the key policy at any time, but there might be a brief delay before the change becomes available throughout AWS KMS. For more information, see [Managing access to customer managed keys](https://docs.aws.amazon.com//kms/latest/developerguide/control-access-overview.html#managing-access) in the *AWS Key Management Service Developer Guide*.
**Encrypt an imported custom model**
To use your customer managed key to encrypt an imported custom model, you must include the following AWS KMS operations in the key policy:
+ [kms:CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) – creates a grant for a customer managed key by allowing the Amazon Bedrock service principal access to the specified KMS key through [grant operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations). For more information about grants, see [Grants in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) in the *AWS Key Management Service Developer Guide*.
**Note**
Amazon Bedrock also sets up a retiring principal and automatically retires the grant after it is no longer required.
+ [kms:DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) – provides the customer managed key details to allow Amazon Bedrock to validate the key.
+ [kms:GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) – Provides the customer managed key details to allow Amazon Bedrock to validate user access. Amazon Bedrock stores generated ciphertext alongside the imported custom model to be used as an additional validation check against imported custom model users
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) – Decrypts the stored ciphertext to validate that the role has proper access to the KMS key that encrypts the imported custom model.
The following is an example policy that you can attach to a key for a role that you'll use to encrypt models that you import:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "KMS key policy for a key to encrypt an imported custom model",
"Statement": [
{
"Sid": "Permissions for model import API invocation role",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/role"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*"
}
]
}
```
------
**Decrypt an encrypted imported custom model**
If you're importing a custom model that has already been encrypted by another customer managed key, you must add `kms:Decrypt` permissions for the same role, as in the following policy:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "KMS key policy for a key that encrypted a custom imported model",
"Statement": [
{
"Sid": "Permissions for model import API invocation role",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/role"
},
"Action": [
"kms:Decrypt"
],
"Resource": "*"
}
]
}
```
------
# Monitoring your encryption keys for the Amazon Bedrock service
When you use an AWS KMS customer managed key with your Amazon Bedrock resources, you can use [AWS CloudTrail](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-user-guide.html) or [Amazon CloudWatch Logs](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) to track requests that Amazon Bedrock sends to AWS KMS.
The following is an example AWS CloudTrail event for [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) to monitor AWS KMS operations called by Amazon Bedrock to create a primary grant:
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAIGDTESTANDEXAMPLE:SampleUser01",
"arn": "arn:aws:sts::111122223333:assumed-role/RoleForModelImport/SampleUser01",
"accountId": "111122223333",
"accessKeyId": "EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAIGDTESTANDEXAMPLE",
"arn": "arn:aws:iam::111122223333:role/RoleForModelImport",
"accountId": "111122223333",
"userName": "RoleForModelImport"
},
"attributes": {
"creationDate": "2024-05-07T21:46:28Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "bedrock.amazonaws.com"
},
"eventTime": "2024-05-07T21:49:44Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-east-1",
"sourceIPAddress": "bedrock.amazonaws.com",
"userAgent": "bedrock.amazonaws.com",
"requestParameters": {
"granteePrincipal": "bedrock.amazonaws.com",
"retiringPrincipal": "bedrock.amazonaws.com",
"keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE",
"operations": [
"Decrypt",
"CreateGrant",
"GenerateDataKey",
"DescribeKey"
]
},
"responseElements": {
"grantId": "0ab0ac0d0b000f00ea00cc0a0e00fc00bce000c000f0000000c0bc0a0000aaafSAMPLE",
"keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE"
},
"requestID": "ff000af-00eb-00ce-0e00-ea000fb0fba0SAMPLE",
"eventID": "ff000af-00eb-00ce-0e00-ea000fb0fba0SAMPLE",
"readOnly": false,
"resources": [
{
"accountId": "111122223333",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111122223333",
"eventCategory": "Management"
}
```
Attach the following resource-based policy to the KMS key by following the steps at [Creating a policy](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-overview.html). The policy contains two statements.
1. Permissions for a role to encrypt model customization artifacts. Add ARNs of the imported custom model builder roles to the `Principal` field.
1. Permissions for a role to use the imported custom model in inference. Add ARNs of imported custom model user roles to the `Principal` field.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "KMS Key Policy",
"Statement": [
{
"Sid": "Permissions for imported model builders",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/role"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*"
},
{
"Sid": "Permissions for imported model users",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/role"
},
"Action": "kms:Decrypt",
"Resource": "*"
}
]
}
```
------
# Encryption in Amazon Bedrock Data Automation
Amazon Bedrock Data Automation (BDA) uses encryption to protect your data at rest. This includes the blueprints, projects, libraries, and extracted insights stored by the service. BDA offers two options for encrypting your data:
1. AWS owned keys – By default, BDA encrypts your data with AWS owned keys. You can't view, manage, or use AWS owned keys, or audit their use. However, you don't have to take any action or change any programs to protect the keys that encrypt your data. For more information, see [AWS owned keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) in the AWS Key Management Service Developer Guide.
1. Customer managed keys – You can choose to encrypt your data with customer managed keys that you manage yourself. For more information about AWS KMS keys, see [Customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in the AWS Key Management Service Developer Guide. BDA does not support customer managed keys for use in the Amazon Bedrock console, only for API operations.
Amazon Bedrock Data Automation automatically enables encryption at rest using AWS owned keys at no charge. If you use a customer managed key, AWS KMS charges apply. For more information about pricing, see AWS KMS [pricing](https://aws.amazon.com/kms/pricing/).
## How Amazon Bedrock uses grants in AWS KMS
If you specify a customer managed key for encryption of your BDA when calling invokeDataAutomationAsync or CreateDataAutomationLibrary, the service creates a grant associated with your resources on your behalf by sending a CreateGrant request to AWS KMS. This grant allows BDA to access and use your customer managed key. The grant created by CreateDataAutomationLibrary is not utilized if the customer ingests vocabulary entities into the library.
BDA uses the grant for your customer managed key for the following internal operations:
+ DescribeKey — Send requests to AWS KMS to verify that the symmetric customer managed AWS KMS key ID you provided is valid.
+ GenerateDataKey and Decrypt — Send requests to AWS KMS to generate data keys encrypted by your customer managed key and decrypt the encrypted data keys so that they can be used to encrypt your resources.
+ CreateGrant — Send requests to AWS KMS to create scoped down grants for the asynchronous execution of operations. The grant operations vary by API:
+ InvokeDataAutomationAsync: DescribeKey, GenerateDataKey, Decrypt
+ CreateDataAutomationLibrary: DescribeKey, GenerateDataKey, Decrypt, CreateGrant
You have full access to your customer managed AWS KMS key. You can revoke access to the grant by following the steps at Retiring and revoking grants in the AWS KMS Developer Guide or remove the service's access to your customer managed key at any time by modifying the key policy. If you do so, BDA won't be able to access the resources encrypted by your key.
If you initiate a new invokeDataAutomationAsync call after revoking a grant, BDA will recreate the grant.
The grants created by invokeDataAutomationAsync are retired by BDA after 30 hours.
The grants created by CreateDataAutomationLibrary are retired by BDA when the library is deleted.
## Creating a customer managed key and attaching a key policy
To encrypt BDA resources with a key that you create and manage, follow these general steps:
1. (Prerequisite) Ensure that your IAM role has permissions for the CreateKey action.
1. Follow the steps at [ Creating keys ](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) to create a customer managed key using the AWS KMS console or the CreateKey operation.
1. Creation of the key returns an ARN that you can use for operations that require using the key (for example, when creating a project or blueprint in BDA), like the invokeDataAutomationAsync operation.
1. Create and attach a key policy to the key with the required permissions. To create a key policy, follow the steps at [ Creating a key policy ](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-create.html) in the AWS KMS Developer Guide.
## Permissions and key policies for Amazon Bedrock Data Automation resources
After you create a AWS KMS key, you attach a key policy to it. The following AWS KMS actions are used for keys that encrypt BDA resources:
1. kms:CreateGrant – Creates a grant for a customer managed key by allowing the BDA service access to the specified AWS KMS key through grant operations, needed for InvokeDataAutomationAsync and CreateDataAutomationLibrary.
1. kms:DescribeKey – Provides the customer managed key details to allow BDA to validate the key.
1. kms:GenerateDataKey – Provides the customer managed key details to allow BDA to validate user access.
1. kms:Decrypt – Decrypts the stored ciphertext to validate that the role has proper access to the AWS KMS key that encrypts the BDA resources.
**Key policy for Amazon Bedrock Data Automation**
To use your customer managed key to encrypt BDA resources, include the following statements in your key policy and replace `${account-id}`, `${region}`, and `${key-id}` with your specific values:
```
{
"Version": "2012-10-17",
"Id": "KMS key policy for a key to encrypt data for BDA resource",
"Statement": [
{
"Sid": "Enable DescribeKey, Decrypt, GenerateDataKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/Role"
},
"Action": [
"kms:DescribeKey",
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "bedrock.us-east-1.amazonaws.com"
}
}
},
{
"Sid": "Enable CreateGrant",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/Role"
},
"Action": "kms:CreateGrant",
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "bedrock.us-east-1.amazonaws.com"
},
"ForAllValues:StringEquals": {
"kms:GrantOperations": [
"CreateGrant",
"GenerateDataKey",
"Decrypt",
"DescribeKey"
]
}
}
}
]
}
```
**IAM role permissions**
The IAM role used to interact with BDA and AWS KMS should have the following permissions, replace `${region}`, `${account-id}`, and `${key-id}` with your specific values:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KeyId",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
## Amazon Bedrock Data Automation encryption context
For all DataAutomationLibrary operations including InvokeDataAutomationLibraryIngestionJob, BDA uses below encryption context in all AWS KMS cryptographic operations, where the key is `aws:bedrock:data-automation-library-arn` and the value is the `libraryArn`.
```
"encryptionContext": {
"aws:bedrock:data-automation-library-arn": ""
}
```
For DataAutomationProject operations, BDA uses below encryption context:
```
"encryptionContext": {
"DataAutomationProjectArn": ""
}
```
For Blueprint operations, BDA uses below encryption context:
```
"encryptionContext": {
"BlueprintArn": ""
}
```
For all other operations, BDA uses below encryption context:
```
"encryptionContext": {
"aws:bedrock:data-automation-customer-account-id": "111122223333"
}
```
**Using encryption context for monitoring**
When you use a symmetric customer managed key to encrypt your data, you can also use the encryption context in audit records and logs to identify how the customer managed key is being used. The encryption context also appears in logs generated by AWS CloudTrail or Amazon CloudWatch Logs.
**Using encryption context to control access to your customer managed key**
You can use the encryption context in key policies and IAM policies as conditions to control access to your symmetric customer managed key. You can also use encryption context constraints in a grant. BDA uses an encryption context constraint in grants to control access to the customer managed key in your account or Region. The grant constraint requires that the operations that the grant allows use the specified encryption context.
The following are example key policy statements to grant access to a customer managed key for a specific encryption context. The condition in this policy statement requires that the grants have an encryption context constraint that specifies the encryption context.
```
[
{
"Sid": "Enable DescribeKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ExampleRole"
},
"Action": ["kms:DescribeKey"],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.${region}.amazonaws.com"
]
}
}
},
{
"Sid": "Enable Decrypt, GenerateDataKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ExampleRole"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.${region}.amazonaws.com"
],
"kms:EncryptionContext:aws:bedrock:data-automation-customer-account-id": "111122223333"
}
}
},
{
"Sid": "Enable CreateGrant",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ExampleRole"
},
"Action": "kms:CreateGrant",
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.${region}.amazonaws.com"
],
"kms:EncryptionContext:aws:bedrock:data-automation-customer-account-id": "111122223333"
},
"StringEquals": {
"kms:GrantOperations": ["Decrypt", "DescribeKey", "GenerateDataKey"]
}
}
}
]
```
When calling `CreateDataAutomationLibrary`, attach the following policy to grant BDA the necessary permission for accessing your customer managed key.
```
[
{
"Sid": "Enable CreateGrant for CreateDataAutomationLibrary",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ExampleRole"
},
"Action": "kms:CreateGrant",
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.${region}.amazonaws.com"
]
},
"StringEquals": {
"kms:GrantOperations": ["Decrypt", "DescribeKey", "GenerateDataKey", "CreateGrant"]
}
}
}
]
```
## Monitoring your encryption keys for Amazon Bedrock Data Automation
When you use an AWS KMS customer managed key with your Amazon Bedrock Data Automation resources, you can use [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) or [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) to track requests that Amazon Bedrock Data Automation sends to AWS KMS. The following is an example AWS CloudTrail event for [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) to monitor AWS KMS operations called by Amazon Bedrock Data Automation to create a primary grant:
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAIGDTESTANDEXAMPLE:SampleUser01",
"arn": "arn:aws:sts::111122223333:assumed-role/RoleForDataAutomation/SampleUser01",
"accountId": "111122223333",
"accessKeyId": "EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAIGDTESTANDEXAMPLE",
"arn": "arn:aws:iam::111122223333:role/RoleForDataAutomation",
"accountId": "111122223333",
"userName": "RoleForDataAutomation"
},
"attributes": {
"creationDate": "2024-05-07T21:46:28Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "bedrock.amazonaws.com"
},
"eventTime": "2024-05-07T21:49:44Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-east-1",
"sourceIPAddress": "bedrock.amazonaws.com",
"userAgent": "bedrock.amazonaws.com",
"requestParameters": {
"granteePrincipal": "bedrock.amazonaws.com",
"retiringPrincipal": "bedrock.amazonaws.com",
"keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE",
"constraints": {
"encryptionContextSubset": {
"aws:bedrock:data-automation-customer-account-id": "000000000000"
}
},
"operations": [
"Decrypt",
"CreateGrant",
"GenerateDataKey",
"DescribeKey"
]
},
"responseElements": {
"grantId": "0ab0ac0d0b000f00ea00cc0a0e00fc00bce000c000f0000000c0bc0a0000aaafSAMPLE",
"keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE"
},
"requestID": "ff000af-00eb-00ce-0e00-ea000fb0fba0SAMPLE",
"eventID": "ff000af-00eb-00ce-0e00-ea000fb0fba0SAMPLE",
"readOnly": false,
"resources": [
{
"accountId": "111122223333",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111122223333",
"eventCategory": "Management"
}
```
# Encryption of agent resources
Encryption of data at rest by default helps reduce the operational overhead and complexity involved in protecting sensitive data. At the same time, it enables you to build secure applications that meet strict encryption compliance and regulatory requirements.
Amazon Bedrock uses default AWS-owned keys to automatically encrypt agent's information. This includes control plane data and session data. You can't view, manage, or audit the use of AWS owned keys. For more information, see [AWS owned keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk).
While you can't disable this layer of encryption, you can choose to use customer managed keys instead of AWS-owned keys to encrypt agent's information. Amazon Bedrock supports the use of a symmetric customer managed keys (CMK) that you can create, own, and manage instead of the default AWS owned encryption. For more information, see [Customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk).
**Important**
Amazon Bedrock automatically encrypts your agent's session information using AWS owned keys at no charge.
AWS KMS charges apply for using a customer managed keys. For more information about pricing, see [AWS Key Management Service Pricing](https://aws.amazon.com/kms/pricing/).
If you've created your agent *before* January 22, 2025 and want to use customer managed key for encrypting agent resources, follow instructions for [Encryption of agent resources for agents created before January 22, 2025](encryption-agents.md).
# Encryption of agent resources with customer managed keys (CMK)
You can at any time create a customer managed key to encrypt your agent’s information using the following agent information provided when building your agent.
**Note**
The following agent resources will only be encrypted for the agents created after January 22, 2025.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/bedrock/latest/userguide/cmk-agent-resources.html)
To use a customer managed key, complete the following steps:
1. Create customer managed key with the AWS Key Management Service.
1. Create a key policy and attach to the customer managed key
## Create a customer managed key
You can create a symmetric customer managed key by using the AWS Management Console, or the AWS Key Management Service APIs.
First make sure that you have `CreateKey` permissions and then, follow the steps for [Creating symmetric customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) in the *AWS Key Management Service Developer Guide*.
**Key policy** - key policies control access to your customer managed key . Every customer managed key must have exactly one key policy, which contains statements that determine who can use the key and how they can use it. When you create your customer managed key, you can specify a key policy. For more information, see [Managing access to customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) in the *AWS Key Management Service Developer Guide*.
If you have created your agent after January 22, 2025 and want to use customer managed key to encrypt your agent's information, make sure that the user or the role calling the agent API operations has the following permissions in the key policy:
+ [kms:GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) – returns a unique symmetric data key for use outside of AWS KMS.
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) – decrypts ciphertext that was encrypted by a KMS key.
Creation of the key returns an `Arn` for the key that you can use as the `customerEncryptionKeyArn`, when creating your agent.
## Create a key policy and attach it to the customer managed key
If you encrypt agent resources with a customer managed key, you must set up an identity-based policy and a resource-based policy to allow Amazon Bedrock to encrypt and decrypt the agent resources on your behalf.
**Identity-based policy**
Attach the following identity-based policy to an IAM role or user with permissions to make calls to agent APIs that encrypt and decrypt agent resources on your behalf. This policy validates the user making API call has AWS KMS permissions. Replace the `${region}`, `${account-id}`, `${agent-id}`, and `${key-id}` with the appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EncryptAgents",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/${key-id}",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock:arn": "arn:aws:bedrock:us-east-1:123456789012:agent/${agent-id}"
}
}
}
]
}
```
------
**Resource-based policy**
Attach the following resource-based policy to your AWS KMS key *only* if you are creating action groups where the schema in Amazon S3 is encrypted. You do not need to attach resource-based policy for any other use cases.
To attach the following resource-based policy, change the scope of the permissions as necessary and replace the `${region}`, `${account-id}`, `${agent-id}`, and `${key-id}` with the appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow account root to modify the KMS key, not used by Amazon Bedrock.",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:*",
"Resource": "arn:aws:kms:us-east-1:123456789012:key/${key-id}"
},
{
"Sid": "Allow Amazon Bedrock to encrypt and decrypt Agent resources on behalf of authorized users",
"Effect": "Allow",
"Principal": {
"Service": "bedrock.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/${key-id}",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock:arn": "arn:aws:bedrock:us-east-1:123456789012:agent/${agent-id}"
}
}
}
]
}
```
------
## Changing the customer managed key
Amazon Bedrock agents do not support re-encryption of versioned agents when the customer managed key associated with the *DRAFT* agent is changed or when you move from customer managed key to AWS owned key. Only the data for the *DRAFT* resource will be re-encrypted with the new key.
Make sure you are not deleting or removing permissions for any keys for a versioned agent if using it to serve production data.
To view and verify the keys being used by a version, call [GetAgentVersion](https://docs.aws.amazon.com//bedrock/latest/APIReference/API_agent_GetAgentVersion.html) and check the `customerEncryptionKeyArn` in the response.
# Encrypt agent sessions with customer managed key (CMK)
If you've enabled memory for your agent and if you encrypt agent sessions with a customer managed key, you must configure the following key policy and the calling identity IAM permissions to configure your customer managed key.
**Customer managed key policy**
Amazon Bedrock uses these permissions to generate encrypted data keys and then use the generated keys to encrypt agent memory. Amazon Bedrock also needs permissions to re-encrypt the the generated data key with different encryption contexts. Re-encrypt permissions are also used when customer managed key transitions between another customer managed key or service owned key. For more information, see [Hierarchical Keyring](https://docs.aws.amazon.com//database-encryption-sdk/latest/devguide/use-hierarchical-keyring.html).
Replace the `$region`, `account-id`, and `${caller-identity-role}` with appropriate values.
```
{
"Version": "2012-10-17",
{
"Sid": "Allow access for bedrock to enable long term memory",
"Effect": "Allow",
"Principal": {
"Service": [
"bedrock.amazonaws.com",
],
},
"Action": [
"kms:GenerateDataKeyWithoutPlainText",
"kms:ReEncrypt*"
],
"Condition": {
"StringEquals": {
"aws:SourceAccount": "$account-id"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:bedrock:$region:$account-id:agent-alias/*"
}
}
"Resource": "*"
},
{
"Sid": "Allow the caller identity control plane permissions for long term memory",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::${account-id}:role/${caller-identity-role}"
},
"Action": [
"kms:GenerateDataKeyWithoutPlainText",
"kms:ReEncrypt*"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:EncryptionContext:aws-crypto-ec:aws:bedrock:arn": "arn:aws:bedrock:${region}:${account-id}:agent-alias/*"
}
}
},
{
"Sid": "Allow the caller identity data plane permissions to decrypt long term memory",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::${account-id}:role/${caller-identity-role}"
},
"Action": [
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:EncryptionContext:aws-crypto-ec:aws:bedrock:arn": "arn:aws:bedrock:${region}:${account-id}:agent-alias/*",
"kms:ViaService": "bedrock.$region.amazonaws.com"
}
}
}
}
```
**IAM permissions to encrypt and decrypt agent memory**
The following IAM permissions are needed for the identity calling Agents API to configure KMS key for agents with memory enabled. Amazon Bedrock agents use these permissions to make sure that the caller identity is authorized to have permissions mentioned in the key policy above for APIs to manage, train, and deploy models. For the APIs that invoke agents, Amazon Bedrock agent uses caller identity's `kms:Decrypt` permissions to decrypty memory.
Replace the `$region`, `account-id`, and `${key-id}` with appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AgentsControlPlaneLongTermMemory",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKeyWithoutPlaintext",
"kms:ReEncrypt*"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KeyId",
"Condition": {
"StringLike": {
"kms:EncryptionContext:aws-crypto-ec:aws:bedrock:arn": "arn:aws:bedrock:us-east-1:123456789012:agent-alias/*"
}
}
},
{
"Sid": "AgentsDataPlaneLongTermMemory",
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KeyId",
"Condition": {
"StringLike": {
"kms:EncryptionContext:aws-crypto-ec:aws:bedrock:arn": "arn:aws:bedrock:us-east-1:123456789012:agent-alias/*"
}
}
}
]
}
```
------
# Preventative security best practice for agents
The following best practices for Amazon Bedrock service can help prevent security incidents:
**Use secure connections**
Always use encrypted connections, such as those that begin with `https://` to keep sensitive information secure in transit.
**Implement least priviledge access to resources**
When you create custom policies for Amazon Bedrock resources, grant only the permissions required to perform a task. It's recommended to start with a minimum set of permissions and grant additional permissions as needed. Implementing least privilege access is essential to reducing the risk and impact that could result from errors or malicious attacks. For more information, see [Identity and access management for Amazon Bedrock](security-iam.md).
**Do not include PII in any of the agent resources containing customer data**
When creating, updating, and deleting agents resources (for example, when using [CreateAgent](https://docs.aws.amazon.com//bedrock/latest/APIReference/API_agent_CreateAgent.html) ) do not include personally-identifiable information (PII) in any fields that do not support using customer managed key such as action group names and knowledgebase names. For the list of fields that support using customer managed key, see [Encryption of agent resources with customer managed keys (CMK)](cmk-agent-resources.md)
# Encryption of agent resources for agents created before January 22, 2025
**Important**
If you've created your agent *after* January 22, 2025, follow instructions for [Encryption of agent resources](encryption-agents-new.md)
Amazon Bedrock encrypts your agent's session information. By default, Amazon Bedrock encrypts this data using an AWS managed key. Optionally, you can encrypt the agent artifacts using a customer managed key.
For more information about AWS KMS keys, see [Customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in the *AWS Key Management Service Developer Guide*.
If you encrypt sessions with your agent with a custom KMS key, you must set up the following identity-based policy and resource-based policy to allow Amazon Bedrock to encrypt and decrypt agent resources on your behalf.
1. Attach the following identity-based policy to an IAM role or user with permissions to make `InvokeAgent` calls. This policy validates the user making an `InvokeAgent` call has KMS permissions. Replace the *\$1\$1region\$1*, *\$1\$1account-id\$1*, *\$1\$1agent-id\$1*, and *\$1\$1key-id\$1* with the appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EncryptDecryptAgents",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/key-id",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock:arn": "arn:aws:bedrock:us-east-1:123456789012:agent/agent-id"
}
}
}
]
}
```
------
1. Attach the following resource-based policy to your KMS key. Change the scope of the permissions as necessary. Replace the *\$1\$1region\$1*, *\$1\$1account-id\$1*, *\$1\$1agent-id\$1*, and *\$1\$1key-id\$1* with the appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRootModifyKMSKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KeyId"
},
{
"Sid": "AllowBedrockEncryptAgent",
"Effect": "Allow",
"Principal": {
"Service": "bedrock.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KeyId",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock:arn": "arn:aws:bedrock:us-east-1:123456789012:agent/AgentId"
}
}
},
{
"Sid": "AllowRoleEncryptAgent",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/Role"
},
"Action": [
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KeyId"
},
{
"Sid": "AllowAttachmentPersistentResources",
"Effect": "Allow",
"Principal": {
"Service": "bedrock.amazonaws.com"
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
------
# Encryption of Amazon Bedrock Flows resources
Amazon Bedrock encrypts your data at rest. By default, Amazon Bedrock encrypts this data using an AWS managed key. Optionally, you can encrypt the data using a customer managed key.
For more information about AWS KMS keys, see [Customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in the *AWS Key Management Service Developer Guide*.
If you encrypt data with a custom KMS key, you must set up the following identity-based policy and resource-based policy to allow Amazon Bedrock to encrypt and decrypt data on your behalf.
1. Attach the following identity-based policy to an IAM role or user with permissions to make Amazon Bedrock Flows API calls. This policy validates the user making Amazon Bedrock Flows calls has KMS permissions. Replace the *\$1\$1region\$1*, *\$1\$1account-id\$1*, *\$1\$1flow-id\$1*, and *\$1\$1key-id\$1* with the appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EncryptFlow",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/${key-id}",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock-flows:arn": "arn:aws:bedrock:us-east-1:123456789012:flow/${flow-id}",
"kms:ViaService": "bedrock.us-east-1.amazonaws.com"
}
}
}
]
}
```
------
1. Attach the following resource-based policy to your KMS key. Change the scope of the permissions as necessary. Replace the *\$1IAM-USER/ROLE-ARN\$1*, *\$1\$1region\$1*, *\$1\$1account-id\$1*, *\$1\$1flow-id\$1*, and *\$1\$1key-id\$1* with the appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRootModifyKMSId",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KeyId"
},
{
"Sid": "AllowRoleUseKMSKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/RoleName"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/${key-id}",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock-flows:arn": "arn:aws:bedrock:us-east-1:123456789012:flow/FlowId",
"kms:ViaService": "bedrock.us-east-1.amazonaws.com"
}
}
}
]
}
```
------
1. For [flow executions](flows-create-async.md), attach the following identity-based policy to a [service role with permissions to create and manage flows](flows-permissions.md). This policy validates that the your service role has AWS KMS permissions. Replace the *region*, *account-id*, *flow-id*, and *key-id* with the appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EncryptionFlows",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/key-id",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock-flows:arn": "arn:aws:bedrock:us-east-1:123456789012:flow/flow-id",
"kms:ViaService": "bedrock.us-east-1.amazonaws.com"
}
}
}
]
}
```
------
# Encryption of knowledge base resources
Amazon Bedrock encrypts resources related to your knowledge bases. By default, Amazon Bedrock encrypts this data using an AWS-owned key. Optionally, you can encrypt the model artifacts using a customer managed key.
Encryption with a KMS key can occur with the following processes:
+ Transient data storage while ingesting your data sources
+ Passing information to OpenSearch Service if you let Amazon Bedrock set up your vector database
+ Querying a knowledge base
The following resources used by your knowledge bases can be encrypted with a KMS key. If you encrypt them, you need to add permissions to decrypt the KMS key.
+ Data sources stored in an Amazon S3 bucket
+ Third-party vector stores
For more information about AWS KMS keys, see [Customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in the *AWS Key Management Service Developer Guide*.
**Note**
Amazon Bedrock knowledge bases uses TLS encryption for communication with third-party data source connectors and vector stores where the provider permits and supports TLS encryption in transit.
**Topics**
+ [Encryption of transient data storage during data ingestion](#encryption-kb-ingestion)
+ [Encryption of information passed to Amazon OpenSearch Service](#encryption-kb-oss)
+ [Encryption of information passed to Amazon S3 Vectors](#encryption-kb-s3-vector)
+ [Encryption of knowledge base retrieval](#encryption-kb-runtime)
+ [Permissions to decrypt your AWS KMS key for your data sources in Amazon S3](#encryption-kb-ds)
+ [Permissions to decrypt an AWS Secrets Manager secret for the vector store containing your knowledge base](#encryption-kb-3p)
+ [Permissions for Bedrock Data Automation (BDA) with AWS KMS encryption](#encryption-kb-bda)
## Encryption of transient data storage during data ingestion
When you set up a data ingestion job for your knowledge base, you can encrypt the job with a custom KMS key.
To allow the creation of a AWS KMS key for transient data storage in the process of ingesting your data source, attach the following policy to your Amazon Bedrock service role. Replace the example values with your own AWS Region, account ID, and AWS KMS key ID.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:123456789012:key/key-id"
]
}
]
}
```
------
## Encryption of information passed to Amazon OpenSearch Service
If you opt to let Amazon Bedrock create a vector store in Amazon OpenSearch Service for your knowledge base, Amazon Bedrock can pass a KMS key that you choose to Amazon OpenSearch Service for encryption. To learn more about encryption in Amazon OpenSearch Service, see [Encryption in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-encryption.html).
## Encryption of information passed to Amazon S3 Vectors
If you opt to let Amazon Bedrock create an S3 vector bucket and vector index in Amazon S3 Vectors for your knowledge base, Amazon Bedrock can pass a KMS key that you choose to Amazon S3 Vectors for encryption. To learn more about encryption in Amazon S3 Vectors, see [Encryption with Amazon S3 Vectors](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-vectors-bucket-encryption.html).
## Encryption of knowledge base retrieval
You can encrypt sessions in which you generate responses from querying a knowledge base with a KMS key. To do so, include the ARN of a KMS key in the `kmsKeyArn` field when making a [RetrieveAndGenerate](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_RetrieveAndGenerate.html) request. Attach the following policy, replacing the example values with your own AWS Region, account ID, and AWS KMS key ID to allow Amazon Bedrock to encrypt the session context.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "bedrock.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/key-id"
}
]
}
```
------
## Permissions to decrypt your AWS KMS key for your data sources in Amazon S3
You store the data sources for your knowledge base in your Amazon S3 bucket. To encrypt these documents at rest, you can use the Amazon S3 SSE-S3 server-side encryption option. With this option, objects are encrypted with service keys managed by the Amazon S3 service.
For more information, see [Protecting data using server-side encryption with Amazon S3-managed encryption keys (SSE-S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html) in the *Amazon Simple Storage Service User Guide*.
If you encrypted your data sources in Amazon S3 with a custom AWS KMS key, attach the following policy to your Amazon Bedrock service role to allow Amazon Bedrock to decrypt your key. Replace the example values with your own AWS Region, account ID, and AWS KMS key ID.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"KMS:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:123456789012:key/key-id"
],
"Condition": {
"StringEquals": {
"kms:ViaService": [
"s3.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
## Permissions to decrypt an AWS Secrets Manager secret for the vector store containing your knowledge base
If the vector store containing your knowledge base is configured with an AWS Secrets Manager secret, you can encrypt the secret with a custom AWS KMS key by following the steps at [Secret encryption and decryption in AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html).
If you do so, you attach the following policy to your Amazon Bedrock service role to allow it to decrypt your key. Replace the example values with your own AWS Region, account ID, and AWS KMS key ID.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:123456789012:key/key-id"
]
}
]
}
```
------
## Permissions for Bedrock Data Automation (BDA) with AWS KMS encryption
When using BDA to process multimodal content with customer-managed AWS KMS keys, additional permissions are required beyond the standard AWS KMS permissions.
Attach the following policy to your Amazon Bedrock service role to allow BDA to work with encrypted multimedia files. Replace the example values with your own AWS Region, account ID, and AWS KMS key ID.
```
{
"Sid": "KmsPermissionStatementForBDA",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "arn:aws:kms:region:account-id:key/key-id",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "account-id",
"kms:ViaService": "bedrock.region.amazonaws.com"
}
}
}
```
The BDA-specific permissions include `kms:DescribeKey` and `kms:CreateGrant` actions, which are required for BDA to process encrypted audio, video, and image files.