Can't access encrypted attribute of block_device_mappings list/map

[ghost]

This issue was originally opened by @estein9825 as hashicorp/terraform#19574. It was migrated here as a result of the provider split. The original body of the issue is below.

---

I need to confirm whether a particular AMI has encryption enabled. My data/output calls to aws_ami are:

data "aws_ami" "target_ami" {
 
  filter {
    name   = "image-id"
    values = ["${var.ami_id}"]
  }
}

output "block device mappings" {
  value = "${data.aws_ami.target_ami.*.block_device_mappings}"
}

results in

[
    [
        map[virtual_name: device_name:/dev/sda1 ebs:map[volume_type:gp2 
encrypted:1 iops:0 snapshot_id:snap-XXXXXXXXX delete_on_termination:1 volume_size:20]
 no_device:]
    ]
]

However, for the life of me, I can't seem to grab that "encrypted" value.

I've tried accessing the data.aws_ami.target_ami.*.block_device_mappings.#.ebs.encrypted attribute like they suggested in the documentation and neither 0 nor * work. It keeps saying

Resource 'data.aws_ami.target_ami' does not have attribute 
'block_device_mappings.0.ebs.encrypted' for variable 'data.aws_ami.target_ami.*.block_device_mappings.0.ebs.encrypted'

The purpose is to ensure that I only grab the appropriate AMI when I create an ec2 instance dynamically.

In otherwords, for

resource "aws_instance" "ec2" {
  count                       = "${var.num_instances}"
  ami                         = "${var.ami_id}"
  associate_public_ip_address = "${var.associate_public_ip_address}"
  instance_type               = "${var.instance_type}"

I want to make sure var.ami_id is encrypted.

I am currently using Terraform v0.11.10.

Hopefully someone knows a way.

[tomelliff]

Unfortunately it's not really possible to get at the EBS volume attributes here. I raised a similar issue with #1623 to build on the work done in #1572 to expose some of these deeply nested attributes.

Coming at it fresh I attempted the following:

output "ebs" {
  value = "${lookup(data.aws_ami.target_ami.0.block_device_mappings[0], "ebs")}"
}

But this errors out as lookup can only work on flat maps, not nested ones like the block_device_mappings has (frustratingly it's the ebs attribute that is a nested map):

Error: Error refreshing state: 1 error(s) occurred:

* output.ebs: lookup: lookup() may only be used with flat maps, this map contains elements of type map in:

${lookup(data.aws_ami.target_ami.0.block_device_mappings[0], "ebs")}

Going another way I tried to get at things by chaining data sources through to the aws_ebs_volume data source so you can filter that on whether it's encrypted (see https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-volumes.html#options). Unfortunately this relies on the volume being both describable by your account (so wouldn't work for public AMIs where only the snapshot is shared) and still lying around and not deleted (and the results expired from the API).

If those constraints work you could do something like this:

data "aws_ebs_snapshot" "root_snapshot" {
  snapshot_ids = ["${data.aws_ami.target_ami.root_snapshot_id}"]
}

data "aws_ebs_volume" "root_volume" {
  most_recent = true

  filter {
    name   = "volume-id"
    values = ["${data.aws_ebs_snapshot.root_snapshot.volume_id}"]
  }

  filter {
    name   = "encrypted"
    values = ["true"]
  }
}

This would tell you whether the AMI is encrypted or not but doesn't influence the AMI selection of the data source (which would be doable if it was filterable directly in the aws_ami data source).

You could decide to follow in the footsteps of #1572 to expose this attribute at a higher level. It's also possible that this becomes easier in 0.12 with the release of HCL2 but I've not had enough of a play with the 0.12 alphas to be sure of that.

In the end I ended up changing how I was doing things so I no longer needed to get at the EBS volume size and this might be an option for you. How are you creating your AMIs that ends up with both encrypted and unencrypted versions for the same filters? I create my AMIs using Packer and when we create an encrypted AMI it first registers an unencrypted AMI, then creates an encrypted snapshot from that before registering a new AMI for the encrypted volume, tags the new AMI and, finally, deleting the old one. As long as at least one of your filter criteria in the aws_ami data source is a tag then you can be sure you are dealing with the encrypted AMI because you never tag the unencrypted AMI.

[estein9825]

We aren’t going to automate ami creation and instead do it manually so it’s not a 100% big deal. I’m just trying to be as comprehensive as possible especially with building our test-kitchen use cases.

[tomelliff]

Is there a reason you aren't automating AMI creation? That seems like a bigger win than writing test cases for Terraform to me.

[estein9825]

Our AMIs won’t be changing regularly. What is your use case where you have to create AMIs regularly?

[tomelliff]

We follow the immutable infrastructure pattern so all changes are baked into AMIs and rolled out. So every time we change something that affects either our base AMI or a specific AMI (such as our ECS cluster AMI) or we apply patches then we need to bake a new AMI (or all the AMIs when the base AMI changes).

[tracypholmes]

Hi, @estein9825! Thank you for using Terraform and for opening up this question. Issues on GitHub are intended to be related to bugs or feature requests with the provider codebase. It appears @tomelliff has provided an answer, as well as some good feedback (thanks)! If needed, please use https://discuss.hashicorp.com/c/terraform-providers for additional feedback, community discussions, and questions around Terraform.

If you believe that your issue was miscategorized as a question or closed in error, please create a new issue using one of the following provided templates: bug report or feature request. Please make sure to provide us with the appropriate information so we can best determine how to assist with the given issue.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!