AWS Virtual Keys
An Alien Virtual Key puts a resource in your own AWS account — an Aurora database, an S3 bucket, a DynamoDB table, an EBS volume — under a key that your customer owns and can revoke.
Nothing moves into the customer's cloud. You keep running the infrastructure you already run, in the account you already run it in. The customer holds one thing: the key that makes their data readable.
An Aurora database in your own AWS account asks AWS KMS for a data key. Because that KMS key is an Alien Virtual Key, KMS sends the already-encrypted data key to Alien over the External Key Store protocol, and Alien wraps it under the key your customer connected — in AWS KMS, Google Cloud KMS, or Azure Key Vault. The resource stays in your account; only the key belongs to the customer, who can disable it at any time.
AWS services already know how to encrypt with KMS. An Alien Virtual Key gives them an ordinary KMS key to point at, while Alien serves the key material behind it through AWS KMS External Key Store (XKS). Your resource sees a normal key ARN. Your customer sees a key they can disable.
Take the Aurora PostgreSQL database above as the example. When Aurora encrypts a page, it asks AWS KMS for a data key exactly as it always has. Because that KMS key is an Alien Virtual Key, KMS hands the data key to Alien over XKS, and Alien wraps it under the cloud key your customer connected. Aurora, your application, and your Terraform never learn that anything unusual happened.
Their key does not have to be in AWS. It can live in their AWS KMS, Google Cloud KMS, or Azure Key Vault, and your AWS resource is encrypted under it either way. A customer standardized on Azure Key Vault can govern the Aurora database you run for them in your own account.
AWS encrypts the data key with its own key material before sending it, so Alien receives ciphertext and returns ciphertext. The plaintext data key never leaves AWS. That makes this a stricter data path than the Encrypt/Decrypt API, where your application does send plaintext to be encrypted.
Because neither party can decrypt alone, a customer who permanently revokes access leaves the data cryptographically unrecoverable — AWS calls this double encryption.
Latency
The key is on the encryption path, so distance matters. AWS advises placing external key store components in the Region closest to the external key manager, and recommends a network round-trip time of 35 ms or less between them.
This is less alarming in practice than it sounds, because AWS services do not call KMS per row or per object. Aurora, S3, and EBS request a data key and reuse it while the resource is in use, so the XKS round trip happens on those key requests rather than on every read and write. Plan for it at resource start-up and failover rather than in your steady-state query path.
Create the key
Create it with the module shown in the dashboard, running Terraform with credentials for your AWS account. deployment_id names the customer whose key backs it:
module "encryption_key" {
source = "pkg.alien.dev/alien/virtual-key/aws"
version = "0.1.0"
deployment_id = "dep_example"
alias = "customer-data"
}
output "kms_key_arn" {
value = module.encryption_key.kms_key_arn
}Point a resource at it
Pass the resulting KMS key ARN to an AWS resource exactly as you would any other customer-managed key:
resource "aws_s3_bucket_server_side_encryption_configuration" "documents" {
bucket = aws_s3_bucket.documents.id
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "aws:kms"
kms_master_key_id = module.encryption_key.kms_key_arn
}
}
}The same key ARN can be used by Aurora, DynamoDB, EBS, or a direct aws kms encrypt call. AWS KMS calls Alien on the encryption path; your application does not call /v1/encrypt for these resources.