Skip to main content

Key Management Service (KMS)

Rationale#

AWS KMS is the service we use for storing and using cryptographic keys. It allows us to have non-readable symmetric and asymmetric private keys hosted in the cloud.

The main reasons why we chose it over other alternatives are:

  1. It integrates with other AWS services like DynamoDB, EKS, S3, EBS, among others.
  2. It uses a state-of-the-art approach for both encryption and decryption in which keys are never exposed. It accomplishes this by making users send the data they want to encrypt/decrypt and then returning it encrypted/decrypted. By doing so, it grants that keys never leave KMS. This approach greatly reduces the chances of key leakage, as plaintext keys can only be obtained via brute-force attacks.
  3. It complies with several certifications from ISO and CSA. Many of these certifications are focused on granting that the entity follows best practices regarding secure cloud-based environments and information security.
  4. It uses hardware security modules validated under FIPS 140-2 so that no one can retireve the existant keys. Such keys are never written to disk and only exist within volatile memory for the time needed to process requests.
  5. It provides a centralized key vault with complete API support where you can store both AWS and customer managed keys, rotate them, log and monitor them, set deleting waiting periods, etc.
  6. It supports a fully granular authentication and access control model, where each key has a policy that specifies what actions users can execute. Aditionally, when combined with AWS IAM, it allows us to specify permissions over general actions like creating keys.
  7. Keys and permissions can be written as code using Terraform.
  8. It integrates with Sops, allowing us to use its keys for encrypting our versioned secrets.

Alternatives#

  1. Google Cloud Key Management: It did not exist at the time we migrated to the cloud. It does not integrate with other AWS services, meaning that an entire platform migration would be required.
  2. Azure Key Vault: It did not exist at the time we migrated to the cloud. It does not integrate with other AWS services, meaning that an entire platform migration would be required.

Usage#

We use AWS KMS for:

  1. DynamoDB Encryption at rest.
  2. S3 Server side encryption.
  3. Encrypting and decrypting our Sops secrets.
  4. Encrypting and decrypting our Kubernetes workers EBS disks.
  5. Encrypting and decrypting our ERP data EBS disk.
  6. Encrypting and decrypting our Okta RADIUS Agent EBS disk.

We do not use AWS KMS for:

  1. Redshift: The database is not encrypted at rest. Pending to implement.
  2. CI Bastion: It does not use EBS encrypted disks as only the base Operating system and other minor dependencies are stored there, as described here.
  3. CI Workers: They do not use EBS encrypted disks as only the base Operating system is stored there, as described here.
  4. Batch workers: They do not use EBS encrypted disks as only the base Operating system is stored there, as described here.

Guidelines#

  1. You can access the AWS KMS console after authenticating on AWS.
  2. Any changes to KMS's infrastructure must be done via Merge Requests.
  3. To learn how to test and apply infrastructure via Terraform, visit the Terraform Guidelines.