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 = trueinroot_block_deviceandebs_block_devicefor 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
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
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.