Rationale​

AWS KMS (Key Management Service) 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

• DynamoDB Encryption at rest;
• S3 server-side encryption;
• encrypting and decrypting our Sops secrets;
• encrypting and decrypting our Kubernetes workers EBS disks;
• encrypting and decrypting our ERP data EBS disk;
• encrypting and decrypting our Okta RADIUS Agent EBS disk.

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);
• CI workers (they do not use EBS encrypted disks, since only the base operating system is stored there);
• Batch workers (they do not use EBS encrypted disks, since only the base operating system is stored there).