Encrypt and decrypt your data with managed keys
Customer-managed encryption keys (CMEK) let you encrypt and decrypt your data with a KMS key you own in your AWS account. You register the key in AWS, and Crusoe uses it at runtime through a role you control.
Customer-managed encryption keys (CMEK) are currently only available for Serverless Fine-Tuning. When you register a CMEK for a project in Crusoe, all future jobs will automatically use the CMEK for encryption and decryption.
How access works
To give CMEK access to the KMS key you store in AWS, you need to:
- Create a single AWS Identity and Access Management (IAM) role in your AWS account that:
- Trusts Crusoe's
CrusoeCMEKrole to assume it, with your Crusoe project ID as theExternalId, for tenant isolation. - Has permission to call
kms:Encrypt,kms:Decrypt,kms:GenerateDataKey, andkms:ReEncrypt*on the specific KMS key you want CMEK to use. Currently, CMEK only callsEncryptandDecrypt.
- Trusts Crusoe's
- Add the role's Amazon Resource Name (ARN) to Crusoe for storage and use at runtime.
Trust chain values
Crusoe provides two values that remain stable across the lifetime of your account: the Crusoe CMEK role ARN and an ExternalId.
| Value | Source | Where you use it | Description |
|---|---|---|---|
| Crusoe CMEK role ARN | arn:aws:iam::1805901 | Principal.AWS in your role's trust policy | The ARN of the Crusoe CMEK role that you'll use in your AWS IAM role's trust policy. |
ExternalId | Your Crusoe project ID(s) | sts:ExternalId condition in your trust policy | The ID that registers the key. To share one KMS key across many projects, list every project ID in the sts:ExternalId condition (StringEquals accepts an array) and register the key in each project. |
Configure CMEK
Use the AWS console (UI) or the AWS CLI to create a KMS key and an IAM role that trusts the CrusoeCMEK role, and then register the key with Crusoe.
Prerequisites
- An AWS account with permission to create KMS keys and IAM roles.
- A Crusoe project ID (used as the
ExternalId). To find your project ID in the console, go to projects and click the copy icon next to the project name. - Access to the Crusoe console to register the key.
- AWS Console (UI)
- AWS CLI
1. Create (or pick) the KMS key
From the KMS console (in your chosen region), go to Customer managed keys and select Create key. Then, fill in the following fields:
- For Key type, enter
Symmetric. - For usage, select
Encrypt and decrypt. Click Next. - For Alias, enter
crusoe-CMEK. - Assign yourself as key administrator and user.
- Click Finish.
- Open the key and copy its ARN:
arn:aws:kms:<region>:<account-id>:key/<key-uuid>.
2. Create the IAM role (trust and KMS policy)
-
In the IAM console, go to Roles → Create role → Custom trust policy, then paste the following and replace the
ExternalIdwith your Crusoe project ID:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Principal": { "AWS": "arn:aws:iam::180590199243:role/CrusoeCMEK" },"Action": "sts:AssumeRole","Condition": {"StringEquals": { "sts:ExternalId": "<your-crusoe-project-id>" }}}]} -
Click Next (skip Attaching managed policies), name the role
CrusoeCMEKKmsAccess, and click Create role. -
Open the role → Add permissions → Create inline policy → JSON, and paste the following, replacing
<your-kms-key-arn>with your key ARN:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": ["kms:Encrypt","kms:Decrypt","kms:GenerateDataKey","kms:ReEncrypt*"],"Resource": "<your-kms-key-arn>"}]} -
Name it
KmsAccessand click Create policy. Copy the role ARN from the role summary.
3. Register the key with Crusoe
To register your key with Crusoe:
1. Create (or pick) the KMS key
aws kms create-key --description "KEK for Crusoe CMEK"
# Note the resulting key ARN: arn:aws:kms:<region>:<your-account-id>:key/<key-uuid>
2. Create the IAM role with the trust and key policies
# Crusoe CMEK role ARN (constant)
CRUSOE_CMEK_ROLE_ARN="arn:aws:iam::180590199243:role/CrusoeCMEK"
# Your Crusoe project ID (the project that registers the key in step 3).
# To share this key across several Crusoe projects, use a JSON array here:
# "sts:ExternalId": ["<project-id-1>", "<project-id-2>"]
EXTERNAL_ID="<your-crusoe-project-id>"
# Your inputs
KMS_KEY_ARN="arn:aws:kms:<region>:<your-account-id>:key/<key-uuid>"
ROLE_NAME="CrusoeCMEKKmsAccess"
cat > trust.json <<EOF
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": { "AWS": "${CRUSOE_CMEK_ROLE_ARN}" },
"Action": "sts:AssumeRole",
"Condition": { "StringEquals": { "sts:ExternalId": "${EXTERNAL_ID}" } }
}]
}
EOF
aws iam create-role \
--role-name ${ROLE_NAME} \
--assume-role-policy-document file://trust.json
cat > kms.json <<EOF
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["kms:Encrypt", "kms:Decrypt", "kms:GenerateDataKey", "kms:ReEncrypt*"],
"Resource": "${KMS_KEY_ARN}"
}]
}
EOF
aws iam put-role-policy \
--role-name ${ROLE_NAME} \
--policy-name KmsAccess \
--policy-document file://kms.json
# Note the resulting role ARN—you register it with Crusoe in step 3.
aws iam get-role --role-name ${ROLE_NAME} --query Role.Arn --output text
3. Register the key with Crusoe
To register your key with Crusoe:
A project may register at most one active external key. A second registration returns 409 Conflict. Delete the existing key first (a soft-deleted key doesn't block a new one).
Crusoe returns an external_key_id (a Crusoe-side identifier) and validates the setup before activating it: CMEK assumes your role, using your Crusoe project ID as the ExternalId, and performs a no-op Encrypt and Decrypt round trip on the key. If validation fails—for example, if the trust policy or ExternalId doesn't match, or the role can't call kms:Encrypt or kms:Decrypt on the key—the registration is rejected with an error describing what failed, so you can fix the trust or key policy and retry. On success, the registration is active and ready for CMEK-protected workloads.
CMEK currently doesn't support key replacement. Registering a new key doesn't re-encrypt data that was encrypted under a previous key. See Revoking access before deleting a registered key.
To use the same key from another Crusoe project, add that project's ID to the sts:ExternalId list in the role's trust policy, then repeat this step from the other project.
Automatic fine-tuning job encryption
When you register a CMEK for a project in Crusoe, all future jobs will automatically use the CMEK for encryption and decryption. To create a fine-tuning job, see Fine-tune a model.
Rotation behavior
Underlying KMS key
Nothing changes on your side. AWS KMS embeds the key version in the ciphertext, so CMEK transparently uses the new version after rotation. No re-registration is required.
CrusoeCMEK role
The CrusoeCMEK role ARN is intentionally stable and won't change. If a migration is ever required, Crusoe will provide explicit migration instructions with a notice.
Revoking access
Delete the role or detach the KMS policy:
aws iam delete-role-policy --role-name CrusoeCMEKKmsAccess --policy-name KmsAccess
aws iam delete-role --role-name CrusoeCMEKKmsAccess
Alternatively, unregister the key through the Crusoe console. This leaves your AWS resources in place and CMEK stops calling them.
Deleting the KMS key causes permanent data loss. CMEK doesn't currently support key replacement: files uploaded to the project are encrypted under the registered key. If that key is deleted in AWS, those files are permanently unrecoverable. Crusoe can't decrypt them, and registering a new key doesn't re-encrypt or recover existing data.
If the key stops working without being deleted (for example, the key is disabled, the role is deleted, or the trust or key policy is broken), data isn't lost. Decryption fails until you restore access, and existing files decrypt again when access is restored.
Reporting
You can audit key usage from your own account. Every CMEK call assumes your role and reaches your KMS key, so it appears in your AWS CloudTrail. The STS role session name is CMEK-<crusoe-project-id>, which lets you attribute each call to the Crusoe project that made it.
Troubleshooting
AccessDenied on AssumeRole when CMEK tries to use the key
- Confirm the
ExternalIdin your trust policy is the Crusoe project ID the key is registered in (every project ID, if shared across projects). - Confirm the
Principalin your trust policy isarn:aws:iam::180590199243:role/CrusoeCMEK(exact, no typos).
Role can be assumed but the KMS call fails
- Check that
kms.jsonwas attached and references the right key ARN. Runaws kms describe-key --key-id <arn>from a session assumed into the role to verify access. - Don't add
Conditionblocks (for example,kms:EncryptionContext:*) to the role's KMS policy or the key policy. Registration validation doesn't send encryption context, so such conditions reject it, and condition denials during later operation surface as opaque failures rather than actionable errors.