AWS recently announced default encryption for EBS volumes, which is incredibly useful for compliant environments. Previously, it was necessary to use AWS Config Rules to identify EBS volumes, either yelling at the person who created them or outright deleting the volume–a potentially dicey proposition. Now, encryption can be enforced by default. This is great, though as usual there are some considerations:

• A few old instance types don’t support EBS encryption. You won’t be able to launch new instances in the C1, M1, M2, or T1 families. Keep in mind that you also won’t be able to attach new volumes, and if you have volume corruption, you’ll only be able to restore from an EBS snapshot of that volume.
• You won’t be able to share AMIs publicly, and any AMIs you share across accounts will need access to your chosen KMS key.
• EBS Snapshots will encrypt with the key used by the volume itself.
• The default encryption settings are per-region. As are the KMS keys.
• Services like RDS and Redshift, which create managed EBS volumes, are unaffected by EBS default encryption.
• If you’re required to use CMKs (and for compliance, you typically are), you need to have a KMS policy that gives the correct permissions. Under-permissioning will give you difficult to troubleshoot launch and snapshot errors, while over-permissioning defeats the purpose.

The last part is the most important and is not necessarily documented in a consistent way. There are a few areas where you need to set the right policies. Each policy example below needs to be rolled into the KMS Key Policy for your CMK.

EC2

EC2 must be granted access to the CMK in order to use it. That access is granted by your users implicitly when launching instances that require the key. Therefore, your IAM users must have permission for the key.

{
  "Version": "2012-10-17", 
  "Statement": [ 
    { 
      "Effect": "Allow", 
      "Action": [ "kms:CreateGrant" ], 
      "Resource": [       
        "arn:aws:kms:REGION:123456789012:key/key-id" 
      ], 
      "Condition": { 
        "Bool": { "kms:GrantIsForAWSResource": true } 
      } 
    } 
  ] 
}

This policy allows the user to delegate access to other AWS resources, such as EC2. It does not allow the user to delegate access to other users, nor does it implicitly give the user access to encrypt/decrypt the key by herself.

Autoscale Groups (ASGs)

ASGs require access to the key, and the policy must be attached to the Service Linked Role (SLR). That requires the SLR to actually exist. The first time you use an ASG, it is implicitly created in your account by AWS. You can also explicitly create it yourself if you need it to exist. Either way, you’ll need to reference the ARN of that service role in the policy below.

{
  "Version": "2012-10-17", 
  "Statement": [ 
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling"
        ]
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling"
        ]
      },
      "Action": [
        "kms:CreateGrant"
      ],
      "Resource": "*",
      "Condition": { 
        "Bool": { "kms:GrantIsForAWSResource": true } 
      } 
    }
  ]
}

Cross-Region Sharing

Keep in mind that KMS keys are region-specific. If you need to decrypt an EBS snapshot in another region, you first need to copy it there. The easiest strategy for this is to pre-configure your KMS CMKs in regions where you’ll need them, with the correct policy in place. Snapshots can be copied with re-encryption handled automatically.

IAM policy works the same for this. The IAM user or role initiating the copy snapshot must have access to kms:CreateGrant for the target key. As a result, be sure to specify the correct region in your ARN.

Cross-Account Sharing

If it is desirable to share AMIs or EBS snapshots across accounts, it becomes necessary to share the CMK itself. Sharing the CMK allows IAM policy administrators (e.g., people with the AdminAccess policy) in that target account to set their own policies. As a result, this should be issued carefully, where you have strong IAM policy governance between accounts. If you’re doing this for AMI sharing alone, consider setting up a separate CMK just for that function. Regardless, you’ll need to set an IAM policy for your user or role in the target account (after sharing the key):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kms:CreateGrant"
      ],
      "Resource": [
        "arn:aws:kms:<SOURCE REGION>:<SOURCE ACCOUNT #>:key/<key id>"
      ],
      "Condition": { 
        "Bool": { "kms:GrantIsForAWSResource": true } 
      } 
    }
  ]
}

This guide from the AWS blog will show you how to share the CMK from the source account, which needs done before the above policy can take effect.

Takeaways

This is a great feature that should be used, and it’s highly recommended you use CMKs so that you’re set up for any current or future compliance requirements. CMKs can be intimidating because of the policy considerations, and this is a low stakes way to dip your toe in the water.