Best way to NOT have an artifact when using the InSpec provisioner?

Packer
1

Our flow:

  1. Build an image
  2. Extract id from manifest
  3. Run another builder with just a “inspec” provisioner to test

So, we successfully build images using packer over a couple of providers.

Afterwards, we extract the image id from the manifest and use the “inspec” provisioner to test our built image. This works fine, but annoyingly creates an image artifact.

For various reasons, we do not want to test in the first build step #1, one of which is we want to do a full power cycle.

So, what would be the best way to not have any artifacts, i.e. they are not created or removed when the builder finishes.

If all else fails, I guess, we’ll have to create a manifest file for the inspec provisioner as well and remove manually.

Open to any other suggestions as well.

Edit: Already read up on

2

How do you define your build block for the inspec run?

3

Here’s my packer file:

{
  "provisioners": [
    {
      "type": "inspec",
      "profile": "inspec-profile"
    }
  ],

  "builders": [
    {
      "type": "digitalocean",
      "api_token": "<TOKEN>",
      "image": "<IMAGE_ID>",
      "region": "nyc3",
      "size": "s-1vcpu-1gb",
      "ssh_username": "<USER>",
      "ssh_agent_auth": "true"
    }
  ]
}

@tbugfinder

4

This is tangential, but why would you want to save an artifact that fails the tests? I typically use the Inspec provisioner as part of the same template, after the “main” provisioning. If the Inspec tests fail I don’t want to keep the artifact, but need to go back and fix the provisioner responsible for making the test pass.

We do the same thing with Trivy – if there’s a vulnerability found in the image, I want to abort the build and address the vulnerability.

I’m aware that there are probably reasons for the way you’re doing things now, but in the interest of “shifting left”, perhaps it might make sense to include the Inspec provisioner in the same template that creates the artifact?

2 Likes
5

First off, thanks for the reponse.

Yep, make sense. I don’t want to store the artifact. This build is part of a jenkins pipeline so if the inspec tests fail, the original provisioner/template manifest is not released.

You have given me food for thought, though. If inspec confirms the build is bad, I would have to remove those artifacts somehow anyways. Hmm… I may end up putting them in the same template like you suggest.

As for why I don’t have it in the same template as the original provisioner right now:

In the past, I’ve had problems on new instances/nodes with packages like google-compute-engine making changes on boot if they haven’t been removed. So inspec in the same template would pass, but fail in a standalone template. Since we use multiple providers, there’s no knowing what the provider may install in their (Debian) image. With the standalone inspec provisioner, these types of things are easier to catch.

So ideally, I would like to test the image on a new instance or at least - if on the provisioner instance - after a power cycle, if I make sense.

6

We have our Inspec as a provisioner after the main install, but we do reboot the instance between. You can just have a shell provisioner that reboots and the following step waiting for the SSH to reappear.

2 Likes