On Feb 16, 2022

Cheat Sheet: AWS KMS

Kyler Middleton
Kyler MiddletonCloud IAM Advocate at IAM Pulse

AWS documentation is comprehensive, but it sometimes feels like you're reading the encyclopedia - there's just so much data! That's why we read the encyclopedia for you, and distilled down what we think are the most important flags for resources and services, and provide example IAM resource policies to give you a running start. Keep an eye out for this series as we build it out to include the most commonly (and most commonly misconfigured) services.

Basics

KMS, or Key Management Service, is the AWS service that stores both Amazon Managed Keys (AMKs) and Customer Managed Keys (CMKs). Keys are used to encrypt data stored in the AWS cloud.

KMS can help provide an extra layer of security beyond IAM - even if a resource is able to access a specific data store or secret, if that resource isn’t also able to access the key that data is encrypted with, it isn’t able to access the clear-text data.

How Does IAM Fit?

Access to keys is managed via IAM resource policies, so IAM is critical here. It’s also possible (and easy!) to accidentally block the root user of the account from accessing the key, which requires AWS support to fix, and that can take some time (read: weeks).

Overview

Facts

  • KMS keys (and KMS key aliases) exist by default in a single region only
    • The “regionality” flag can be set to permit replicating the key to other regions, but key policies (resource IAM policies) are not replicated
  • CMK (Customer Managed Keys) mean AWS doesn’t possess the private key, and is unable to read your encrypted data, great for regulated industries like healthcare and payment card info/PCI
  • KMS key policies can lock the root user out of managing the key, be cautious to include a root user permission along with any other changes you make

KMS IAM Policy Examples

This is the default KMS resource policy. If you build a new policy, make sure to add on to this existing policy template, or else you might lock your root user (and yourself!) out of reading or writing this key.

1{
2  "Version": "2012-10-17",
3  "Id": "key-default-1",
4  "Statement": [
5    {
6      "Sid": "Enable IAM Root Permissions",
7      "Effect": "Allow",
8      "Principal": {
9        "AWS": "arn:aws:iam::1111111111:root"
10      },
11      "Action": "kms:*",
12      "Resource": "*"
13    }
14  ]
15}

Permitting access to remote IAM roles (those in other accounts) to decrypt the KMS key. Note we added permissions on top of the root admin rights.

1{
2  "Version" : "2012-10-17",
3  "Id" : "Cross Account Permits",
4  "Statement" : [
5    {
6      "Sid": "Enable IAM User Permissions",
7      "Effect": "Allow",
8      "Principal": {
9        "AWS": "arn:aws:iam::1111111111:root"
10      },
11      "Action": "kms:*",
12      "Resource": "*"
13    },
14    {
15      "Sid" : "Cross Account Permits",
16      "Effect" : "Allow",
17      "Action" : [
18        "kms:Decrypt",
19        "kms:DescribeKey"
20      ],
21      "Resource" : "*",
22      "Principal" : {
23        "AWS" : [
24          "arn:aws:iam::22222222222:role/RoleName1",
25          "arn:aws:iam::33333333333:role/RoleName2"
26        ]
27      }
28    }
29  ]
30}

KMS Configuration Options

IAM-Related Options

  • Resource Policy (root user access only) - Controls who can access the key. By default only accessible to the root user.

Other Options

  • Alias (set, not set) - Alias is a human-readable name that is linked to a specific key. This is required if building a key in the console, but isn’t required if building via API (or Terraform). Multiple aliases to a single key are supported.
    • Recommendation: Set Alias to something memorable
  • Key Type (Symmetrical, Asymmetrical) - Keys can be used for simple data encryption, or for other purposes. More information in the docs
    • Recommendation: Leave as SYMMETRICAL_DEFAULT unless you have a specific use case.
  • Regionality (Single-Region, Multi-Region) - Keys exist in one region by default, unless this is set on key creation. If set to multi-region, key and contents can be replicated to other regions and be accessible locally to services there. If replicating keys, policies are not replicated
    • Recommendation: Leave as single region unless you may need it in other regions in the future
    • Risk: Regionality cannot be changed later - recreating the key is the only way to change this setting

    Get the IAM Pulse Check Newsletter

    We send out a periodic newsletter full of tips & tricks, contributions from the community, commentary on the industry, relevant social posts, and more.

    Checkout past issues for a sampling of the goods.