AWS block-device mappings without encryption

Explicitly request EBS encryption in EC2 block-device mappings and verify the resulting volumes.

Description

Block-device mappings are reused when creating instances. A configuration that creates unencrypted EBS volumes can affect application data and logs across multiple servers.

Actual encryption also depends on source snapshots and the account’s regional EBS encryption default. Check the resulting volume rather than infer its state solely from an omitted option or false.

Potential impact

Unauthorized acquisition of unencrypted volumes or snapshots can expose sensitive data. Organizational storage-encryption requirements may also be unmet.

Remediation

  • Set encrypted = true in root_block_device and ebs_block_device for new EBS volumes, including reusable creation templates.
  • Check EBS encryption by default and KMS permissions in each Region in use. Use launch templates for new Auto Scaling configurations.
  • Migrate an existing unencrypted volume through an encrypted snapshot copy and a new volume. Review Terraform replacement, data consistency and attachment cutover.

Examples

These excerpts attach an additional EBS volume to an EC2 instance. Supply a valid AMI, networking and the remaining configuration.

Before

hcl
resource "aws_instance" "example" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "m4.large"

  ebs_block_device {
    device_name = "/dev/sdf"
    volume_size = 20
    encrypted   = false
  }
}

This does not explicitly request encryption for the additional volume. Check its actual state according to its source and regional defaults.

After

hcl
resource "aws_instance" "example" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "m4.large"

  ebs_block_device {
    device_name = "/dev/sdf"
    volume_size = 20
    encrypted   = true
  }
}

This requests encryption for the additional volume. Check the root volume separately, and do not assume existing volumes are encrypted automatically.

References