c3.1 Encrypt the knowledge base and vector store with a CMK

RAG data needs encryption at several points

A knowledge base moves your data through several stages, each a place data sits or transits: the S3 data sources, the data ingestion job that chunks and embeds them, transient storage Bedrock uses during ingestion, the vector store, and the query sessions at retrieval time. A customer managed KMS key (CMK) lets you bring all of these under a key whose access you control and audit, instead of relying on default AWS managed keys you cannot inspect.

Let Bedrock use your key

As with other Bedrock features, the key policy grants the service principal the needed operations, scoped to Bedrock with kms:ViaService:

{
  "Sid": "AllowBedrockKnowledgeBaseUseOfKey",
  "Effect": "Allow",
  "Principal": { "Service": "bedrock.amazonaws.com" },
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:GenerateDataKey",
    "kms:CreateGrant",
    "kms:DescribeKey"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": { "kms:ViaService": "bedrock.us-east-1.amazonaws.com" }
  }
}

Encrypt each stage, not just one

• Data sources: enable SSE-KMS with this CMK on the S3 bucket holding the source documents.
• Transient data during ingestion: pass the CMK when you create the data source / ingestion configuration so Bedrock encrypts intermediate data with your key.
• Vector store: encrypt the OpenSearch Serverless collection (or your chosen store) with a CMK — configured on the store itself.
• Query sessions: supply a CMK for the session data at retrieval time so prompts and retrieved context are encrypted with your key.

A chain is only as strong as its weakest link: if the vector store falls back to a default key, the embeddings of your confidential data are protected by a key you do not control.

Give the service role decrypt on the key

The knowledge base service role (see the least-privilege KB role control) needs kms:Decrypt (and kms:GenerateDataKey) on this key, or ingestion and retrieval fail with access errors. Keep key administration in a separate role from key use.

Naming note: replace the Region in kms:ViaService and use a Region-local CMK. Use the same key consistently across sources, store, and sessions so nothing falls back to a default key.