Test Kitchen - `kitchen.container.yml`
Understanding the kitchen.container.yml
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: ubi8
suites:
- name: vanilla
driver:
image: <%= ENV['VANILLA_CONTAINER_IMAGE'] || "registry.access.redhat.com/ubi8/ubi:8.9-1028" %>
verifier:
input_files:
- container.vanilla.inputs.yml
- name: hardened
driver:
image: <%= ENV['HARDENED_CONTAINER_IMAGE'] || "registry1.dso.mil/ironbank/redhat/ubi/ubi8" %>
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 a 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: ubi8
This section defines the platforms on which your tests will run. In this case, it's UBI 8 (Red Hat's Universal Base Image 8).
suites:
- name: vanilla
driver:
image: <%= ENV['VANILLA_CONTAINER_IMAGE'] || "registry.access.redhat.com/ubi8/ubi:8.9-1028" %>
verifier:
input_files:
- container.vanilla.inputs.yml
- name: hardened
driver:
image: <%= ENV['HARDENED_CONTAINER_IMAGE'] || "registry1.dso.mil/ironbank/redhat/ubi/ubi8" %>
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
, adriver
, and averifier
. - The
driver
section specifies the Docker image to use for the suite. It's dynamically set based on theVANILLA_CONTAINER_IMAGE
orHARDENED_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:
- Create: Test Kitchen uses the driver to create a Docker container of the platform.
- Converge: Test Kitchen uses the provisioner to apply the infrastructure code to the container. In this case, no provisioning is done.
- 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. - 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/ubi8/ubi:8.9-1028
- default:
HARDENED_CONTAINER_IMAGE
: This variable specifies the Docker container image considered 'hardened'.- default:
registry1.dso.mil/ironbank/redhat/ubi/ubi8
- default: