Schedule Image Iteration Revocation for Compliance

Over the lifecycle of a machine image, you may need to prevent access to it if it becomes outdated. In addition to immediately revoking insecure image iterations, HCP Packer lets you schedule a future image revocation by setting a Time To Live (TTL). This strengthens your compliance posture by by preventing usage of outdated images.

In this tutorial, you will schedule a revocation. In the process, you will learn the relationship between HCP Packer image channels and revoked iterations, and how image revocation prevents downstream image consumers from referencing outdated images.

»Prerequisites

To complete this tutorial, you must have completed the HCP Packer Get Started collection. In the collection, you:

• Created a service principal.
• Set your client ID and secret as environment variables.
• Configured your AWS credentials as environment variables.
• Built an image and push its metadata to HCP Packer.
• Set up a channel named production for your image bucket.

»Schedule image iteration revocation

Assume that your company policy requires that images expire after 30 days to ensure no one deploys a stale image. To enforce this policy, you can schedule a revocation date and time.

Go to the learn-packer-ubuntu's Iterations page. Schedule a revocation date for the first iteration by clicking on ... then Revoke iteration. Scheduled revocations, unlike immediate ones, can apply to iterations assigned to image channels.

Select Revoke at a future date and enter the time for 5 minutes from your current time. The time is in UTC (current time in UTC). For example, if it is currently 10:00, enter 10:05.

Enter Learning about scheduling revocation for the revocation reason, and click Revoke Iteration to revoke the iteration.

The dashboard now shows a scheduled revocation for the first iteration.

Open the first iteration by clicking on 1. HCP Packer displays the reason why this image was scheduled to be revoked.

»Verify scheduled image iteration revocation

Since HCP Packer has not revoked the first iteration yet, you can still query both the image channel and the image iteration.

In the tf-channel direcotry, generate a Terraform plan. Terraform will successfully create the plan since HCP Packer hasn't revoked the iteration yet.

$ terraform plan

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_instance.app_server will be created
  + resource "aws_instance" "app_server" {
      + ami                                  = "ami-08fd..."
      ## ...
    }

Plan: 1 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't
guarantee to take exactly these actions if you run "terraform apply" now.

$ terraform plan

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_instance.app_server will be created
  + resource "aws_instance" "app_server" {
      + ami                                  = "ami-08fd..."
      ## ...
    }

Plan: 1 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't
guarantee to take exactly these actions if you run "terraform apply" now.

The hcp_packer_iteration and hcp_packer_image Terraform data sources still retrieve information for revoked iterations. However, for revoked images, the hcp_packer_image data source's cloud_image_id attribute is set to error_revoked.

In main.tf, update the EC2 instance to only create an instance if the image is not revoked.

resource "aws_instance" "app_server" {
  count = data.hcp_packer_image.ubuntu_us_east_2.cloud_image_id == "error_revoked" ? 0 : 1

  ami           = data.hcp_packer_image.ubuntu_us_east_2.cloud_image_id
  instance_type = "t2.micro"
  tags = {
    Name = "Learn-HCP-Packer"
  }
}

resource "aws_instance" "app_server" {
  count = data.hcp_packer_image.ubuntu_us_east_2.cloud_image_id == "error_revoked" ? 0 : 1

  ami           = data.hcp_packer_image.ubuntu_us_east_2.cloud_image_id
  instance_type = "t2.micro"
  tags = {
    Name = "Learn-HCP-Packer"
  }
}

In outputs.tf, add the following output to view the iteration's image ID.

output "image_status" {
  value = data.hcp_packer_image.ubuntu_us_east_2.cloud_image_id
}

output "image_status" {
  value = data.hcp_packer_image.ubuntu_us_east_2.cloud_image_id
}

Wait until the five minute revocation time you configured earlier passes. HCP Packer will automatically revoke your iteration. Check the Iterations dashboard to confirm HCP Packer revoked the first iteration.

Notice that even though the first iteration is revoked, the production channel still references it.

Generate a Terraform plan. Since the production channel references a revoked image, the image_status output is set to error_revoked and Terraform will not create the EC2 instance.

$ terraform plan

Changes to Outputs:
  + image_status     = "error_revoked"
  + ubuntu_iteration = {
      ## ...
    }
  + ubuntu_us_east_2 = {
      + bucket_name     = "learn-packer-ubuntu"
      + build_id        = "01FX9NHNH7B5EF33Q8WKSH641C"
      + cloud_image_id  = "error_revoked"
      ## ...
    }

You can apply this plan to save these new output values to the
Terraform state, without changing any real infrastructure.

───────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform
can't guarantee to take exactly these actions if you run "terraform
apply" now.

$ terraform plan

Changes to Outputs:
  + image_status     = "error_revoked"
  + ubuntu_iteration = {
      ## ...
    }
  + ubuntu_us_east_2 = {
      + bucket_name     = "learn-packer-ubuntu"
      + build_id        = "01FX9NHNH7B5EF33Q8WKSH641C"
      + cloud_image_id  = "error_revoked"
      ## ...
    }

You can apply this plan to save these new output values to the
Terraform state, without changing any real infrastructure.

───────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform
can't guarantee to take exactly these actions if you run "terraform
apply" now.

If your Terraform configuration references a revoked image, contact your HCP Packer administrator to re-assign the channel to a valid image iteration.

»Restore revoked iteration

If you accidentally revoke the wrong iteration, you can restore the iteration so your team can use its images again.

In the HCP Packer UI, navigate to the first iteration. Then, click Manage and Restore iteration.

Click Restore iteration to restore your iteration.

»Verify restoration

In the tf-channels directory, generate a plan. Since the iteration is restored, Terraform successfully creates a plan.

$ terraform plan

Terraform used the selected providers to generate the following
execution plan. Resource actions are indicated with the following
symbols:
  + create

Terraform will perform the following actions:

  # aws_instance.app_server[0] will be created
  + resource "aws_instance" "app_server" {
      + ami                                  = "ami-08fd..."
      ## ...
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + image_status = "ami-08fd..."

───────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform
can't guarantee to take exactly these actions if you run "terraform
apply" now.

$ terraform plan

Terraform used the selected providers to generate the following
execution plan. Resource actions are indicated with the following
symbols:
  + create

Terraform will perform the following actions:

  # aws_instance.app_server[0] will be created
  + resource "aws_instance" "app_server" {
      + ami                                  = "ami-08fd..."
      ## ...
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + image_status = "ami-08fd..."

───────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform
can't guarantee to take exactly these actions if you run "terraform
apply" now.

»Next steps

In this tutorial, you used scheduled an iteration revocation and restored a revoked iteration. In the process, you reviewed how scheduled revocations strengthen your compliance posture by setting expiration dates on iterations, preventing users from using outdated images. Though you can schedule a revocation for an iteration assigned to an image channel, when the revocation date passes, the channel will reference a revoked iteration. Any attempts to query a channel with a revoked iteration will fail.

By integrating both immediate and scheduled iteration revocation in your workflows, you can ensure your organization uses secure and compliant images.

For more information on topics covered in this tutorial, check out the following resources:

• Complete the Immediately Revoke Insecure Image Iterations tutorial to learn how to prevent users from referencing insecure images.
• Read more about revoking image iterations in the HCP Packer documentation.
• Visit the Terraform hcp provider for a full list of arguments and attributes for the hcp_packer_iteration and hcp_packer_image data resources.
• Complete the Set Up Terraform Cloud Run Task for HCP Packer tutorial to learn how to ensure your Terraform configuration uses compliant machine images.