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 the following:

  • It integrates with other AWS services like DynamoDB, EKS, S3, EBS, among others.
  • 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, keys never leave KMS. This approach greatly reduces the chances of key leakage, as plaintext keys can only be obtained via brute-force attacks.
  • 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.
  • It uses hardware security modules validated under FIPS 140-2 so that no one can retrieve the existent keys. Such keys are never written to disk and only exist within volatile memory for the time needed to process requests.
  • 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.
  • It supports a fully granular authentication and access control model, where each key has a policy that specifies what actions users can execute. Additionally, when combined with AWS IAM, it allows us to specify permissions over general actions like creating keys.
  • Keys and permissions can be written as code using Terraform.
  • It integrates with Sops, allowing us to use its keys for encrypting our versioned secrets.

Alternatives​

  • 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.
  • 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

We do not use AWS KMS for

  • Redshift (the database is not encrypted at rest; this implementation is pending);
  • CI Bastion (it does not use EBS encrypted disks, since only the base operating system and other minor dependencies are stored there, as described here);
  • CI workers (they do not use EBS encrypted disks, since only the base operating system is stored there, as described here);
  • Batch workers (they do not use EBS encrypted disks, since only the base operating system is stored there, as described here).

Guidelines​

Last updated on