Understanding the kitchen.container.yml File

The kitchen.container.yml file orchestrates our container-based test suite. It defines two types of containers: hardened and vanilla, and specifies the InSpec tests to run against them. It also configures the generation and storage of test reports.

Unlike other test suites, the container suite skips the 'provisioner' stage for the vanilla and hardened targets. Instead, during the create stage, it simply downloads and starts the specified images. This is due to the use of the dummy Test Kitchen driver, which is ideal for interacting with pre-configured or immutable targets like containers.

This approach allows for the evaluation of existing containers, even those created by other workflows. It can be leveraged to build a generalized workflow for validating any container against our Benchmark requirements, providing a comprehensive assessment of its security posture.

Example kitchen.container.yml file

---
# see: https://kitchen.ci/docs/drivers/dokken/

provisioner:
  name: dummy

driver:
  name: dokken
  pull_platform_image: false

transport:
  name: dokken

platforms:
  - name: ubi9

suites:
  - name: vanilla
    driver:
      image: <%= ENV['VANILLA_CONTAINER_IMAGE'] || "registry.access.redhat.com/ubi9/ubi:9.3-1610" %>
    verifier:
      input_files:
        - container.vanilla.inputs.yml
  - name: hardened
    driver:
      image: <%= ENV['HARDENED_CONTAINER_IMAGE'] || "registry1.dso.mil/ironbank/redhat/ubi/ubi9" %>
    verifier:
      input_files:
        - container.hardened.inputs.yml
      # creds_file: './creds.json'

Breakdown of the kitchen.container.yml file

provisioner:
  name: dummy

This section configures the provisioner, which is the tool that brings your system to the desired state. Here, it's using the dummy provisioner, which means no provisioning will be done.

driver:
  name: dokken
  pull_platform_image: false

This section configures the driver, which is responsible for creating and managing the instances. Here, it's set to use the Dokken driver, which is designed for running tests in Docker containers. The pull_platform_image: false option means that it won't automatically pull the Docker image for the platform; it will use the image specified in the suite.

transport:
  name: dokken

This section configures the transport, which is the method Test Kitchen uses to communicate with the instance. Here, it's using the Dokken transport, which communicates with the Docker container.

platforms:
  - name: ubi9

This section defines the platforms on which your tests will run. In this case, it's UBI 9 (Red Hat's Universal Base Image 9).

suites:
  - name: vanilla
    driver:
      image: <%= ENV['VANILLA_CONTAINER_IMAGE'] || "registry.access.redhat.com/ubi9/ubi:9.3-1610" %>
    verifier:
      input_files:
        - container.vanilla.inputs.yml
  - name: hardened
    driver:
      image: <%= ENV['HARDENED_CONTAINER_IMAGE'] || "registry1.dso.mil/ironbank/redhat/ubi/ubi9" %>
    verifier:
      input_files:
        - container.hardened.inputs.yml

This section defines the test suites. Each suite represents a different configuration to test.

• Each suite has a name, a driver, and a verifier.
• The driver section specifies the Docker image to use for the suite. It's dynamically set based on the VANILLA_CONTAINER_IMAGE or HARDENED_CONTAINER_IMAGE environment variable, with a default value if the variable is not set.
• The verifier section specifies files that contain input variables for the InSpec profile.

The workflow of Test Kitchen involves the following steps:

1. Create: Test Kitchen uses the driver to create a Docker container of the platform.
2. Converge: Test Kitchen uses the provisioner to apply the infrastructure code to the container. In this case, no provisioning is done.
3. Verify: Test Kitchen checks if the container is in the desired state. This is not shown in your file, but it would be configured in the verifier section.
4. Destroy: Test Kitchen uses the driver to destroy the container after testing. This is not shown in your file, but it would be configured in the driver section.

The transport is used in all these steps to communicate with the container.

Environment Variables in kitchen.container.yml

The kitchen.container.yml file uses the following environment variables to select the containers used during its hardened and vanilla testing runs. You can test any container using these environment variables, even though standard defaults are set.

• VANILLA_CONTAINER_IMAGE: This variable specifies the Docker container image considered 'not hardened'.
  • default: registry.access.redhat.com/ubi9/ubi:9.3-1610
• HARDENED_CONTAINER_IMAGE: This variable specifies the Docker container image considered 'hardened'.
  • default: registry1.dso.mil/ironbank/redhat/ubi/ubi9