Skip to main content

Enable Customer‑Managed Encryption Keys (CMEK) for Your Oloid Tenant (AWS KMS “KEK Encryption”)

Audience: Customer cloud/security/IAM administrators Applies to: Any Oloid tenant (no additional packages/features required)

Updated this week

At a glance

  • Customer-managed: You (the customer) create and manage the AWS KMS key (the Key-Encryption Key / KEK).

  • Oloid’s access: Oloid does not have direct access to your key management; Oloid only uses the permissions you grant in your KMS Key Policy.

  • Configuration: Oloid configures only the KMS key ARN in Oloid infrastructure for your tenant.

  • Verification: You can verify encryption by changing the KMS Key Policy to allow/deny Oloid and observing behavior.

  • Critical safety: NEVER DELETE the KMS key used for your tenant. If the key is deleted, data recovery is not possible.


How it works (high level)

Oloid uses AWS KMS for envelope encryption. Your symmetric KMS key (KEK) protects short-lived data keys, which encrypt the tenant’s data at rest. If your key is disabled, the policy is tightened to remove Oloid access, or the key is deleted, Oloid cannot decrypt tenant data.


Roles & responsibilities

You (Customer)

Oloid

Create and own a customer-managed, symmetric AWS KMS key in the region required for your tenant.

Provide the AWS principal ARN(s) that require “use” permissions on your KMS key.

Apply a Key Policy that authorizes Oloid to use (not manage) the key.

Store only your KMS key ARN and perform encryption/decryption via KMS under your policy.

Share only the key ARN with Oloid via your approved secure channel.

Enable CMEK for your tenant using your key ARN.

Manage monitoring and key lifecycle (never delete the key).

Support validation tests if you change key policy or temporarily disable the key.



Prerequisites

  • AWS account permissions to create/manage AWS KMS (symmetric) keys in the required region.

  • Ability to edit KMS Key Policy (JSON) and manage IAM.

  • Secure channel to share the KMS key ARN with Oloid.


Step-by-step: Production enablement (Acme Corp / “acmecorp” tenant)

Region: Create the key in the region specified by your Oloid representative (example: us-east-1).

1) Create a new symmetric KMS key

  • Console: KMS → Customer managed keysCreate keySymmetric → Key usage: Encrypt/Decrypt.

  • (Optional) CLI:

    aws kms create-key \
    --description "Oloid CMEK - acmecorp (prod)" \
    --key-usage ENCRYPT_DECRYPT \
    --origin AWS_KMS \
    --region <YOUR-REGION>

2) Apply the Key Policy to allow Oloid to use your key

Important — policies evolve: Since policies are updated, get the latest policy list from your OLOID representative. The policy below is an example for reference only.

Paste the JSON below into the key’s policy (Console → Key policy → Edit), replacing placeholders with values provided by your Oloid representative.

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EnableAccountAdmins",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::<YOUR_AWS_ACCOUNT_ID>:root" },
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "AllowOloidUseOfKey",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::<OLOID_ACCOUNT_ID>:role/<OLOID_KMS_ACCESS_ROLE>"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "AllowOloidGrantsForAWSResources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::<OLOID_ACCOUNT_ID>:role/<OLOID_KMS_ACCESS_ROLE>"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": { "Bool": { "kms:GrantIsForAWSResource": true } }
}
]
}

What these statements do

  • AllowOloidUseOfKey: Grants Oloid the minimum use permissions to perform envelope encryption.

  • AllowOloidGrantsForAWSResources: Lets Oloid create tightly scoped grants when AWS services (e.g., databases, storage) need resource-level access under your key—without broadening the policy.

Optional hardening (add only if confirmed by your Oloid representative):
You may restrict usage to specific AWS services/region with kms:ViaService:

"Condition": {
"ForAnyValue:StringEquals": {
"kms:ViaService": [ "rds.<YOUR-REGION>.amazonaws.com", "dynamodb.<YOUR-REGION>.amazonaws.com" ]
}
}

3) Share the key ARN with Oloid

Provide the key ARN (or alias ARN) via your approved secure channel, for example:
arn:aws:kms:<YOUR-REGION>:<YOUR_AWS_ACCOUNT_ID>:key/1234abcd-...

4) Oloid enables CMEK for your tenant

Oloid records your key ARN in tenant configuration and begins using your key for all new cryptographic operations.


Validate encryption (recommended)

You can confirm that Oloid is enforcing your KMS controls in either of the following ways.
Coordinate with your Oloid contact and avoid business-critical windows before running these tests.

Option A — Temporary policy deny

  1. In the Key Policy, temporarily remove or deny the Oloid principal statements.

  2. Perform an Oloid action that requires decryption (e.g., read an encrypted record).

  3. The operation should fail while access is removed.

  4. Restore the Key Policy; the operation should succeed again.

Option B — Temporarily disable the key

  1. Temporarily disable the KMS key.

  2. Perform a decrypt-requiring action; it should fail.

  3. Re-enable the key; the action should succeed again.

Do not delete the key for testing.


Ongoing operations & guardrails

  • Monitoring: Use CloudTrail/KMS metrics to audit Encrypt/Decrypt and grant activity; review the Key Policy periodically.

  • Access changes: To revoke Oloid access, update the Key Policy to remove Oloid principals or disable the key (preferred for temporary lockout).

  • Lifecycle: If you intend to migrate to a new key, coordinate with Oloid to re-encrypt before retiring the old key.

  • Irreversibility: NEVER DELETE the KMS key protecting your tenant. Data recovery is not possible if the key is deleted.


Migration scenarios (example: Acme Corp)

Preview (non-prod)

  • kek-acme tenant was created only to test encryption and should not be used further.

  • For the production acmecorp tenant, Oloid will enable encryption using either the same key as kek-acme or a newKMS key provided by Acme (recommended).

Production

  1. Create a new symmetric AWS KMS key in the region specified by Oloid (example: us-east-1).

  2. Apply the latest Oloid-approved Key Policy (example above; request the current version from your Oloid representative).

  3. Share the key ARN with Oloid via your secure channel.

  4. Oloid enables encryption using this key for your production tenant.

  5. Do not delete the key. If you need to pause usage, disable it instead and coordinate with Oloid.


FAQ

Q: What key type should we create?
A: A customer-managed, symmetric KMS key with Encrypt/Decrypt usage in the region requested by Oloid.

Q: Does Oloid ever get our key material?
A: No. Oloid is authorized by your Key Policy only to use the key. Oloid stores only the key ARN and makes KMS API calls permitted by your policy.

Q: Can we restrict the key to specific AWS services or regions?
A: Yes—use kms:ViaService conditions only for services/regions confirmed by your Oloid representative.

Q: How do we prove CMEK is working?
A: Temporarily remove Oloid access in the Key Policy or temporarily disable the key; operations needing decryption will fail until access is restored.


Appendix A — Minimal CLI cheat-sheet

# 1) Create a symmetric key (prod)
aws kms create-key \
--description "Oloid CMEK - <Tenant> (prod)" \
--key-usage ENCRYPT_DECRYPT \
--origin AWS_KMS \
--region <YOUR-REGION>

# 2) (Optional) Create a friendly alias
aws kms create-alias \
--alias-name alias/oloid/<tenant>/prod \
--target-key-id <KeyId> \
--region <YOUR-REGION>

# 3) Apply/replace policy
aws kms put-key-policy \
--key-id <KeyArnOrId> \
--policy-name default \
--policy file://oloid-cmek-policy.json \
--region <YOUR-REGION>

Appendix B — Optional policy hardening snippets

Heads-up: Policies are updated periodically. Request the latest OLOID-approved policy statementsfrom your Oloid representative. The snippets below are examples only.

Restrict to specific AWS services/region via kms:ViaService:

"Condition": {
"ForAnyValue:StringEquals": {
"kms:ViaService": [ "rds.<YOUR-REGION>.amazonaws.com", "dynamodb.<YOUR-REGION>.amazonaws.com" ]
}
}

Grant-based model when AWS services need persistent access:
Use the AllowOloidGrantsForAWSResources statement (in the example Key Policy) with
"Condition": { "Bool": { "kms:GrantIsForAWSResource": true } }.


Strong warnings (repeat)

  • NEVER DELETE the AWS KMS key used for your Oloid tenant; data recovery is not possible if the key is deleted.

  • If you need to pause or test access, disable the key or update the Key Policy instead of deleting the key.

Did this answer your question?