Skip to main content

Test Kitchen - `kitchen.yml` File

Aaron LippoldAbout 2 min

Understanding the kitchen.yml File

The kitchen.yml file is the primary configuration file for Test Kitchen. It outlines the shared configuration for all your testing environments, platforms, and the testing framework to be used.

Each of the subsequent kitchen files will inherit the shared settings from this file automatlly and merge them with the setting in the child kitchen file.

Example kitchen.yml file

---
verifier:
  name: inspec
  sudo: true
  reporter:
    - cli
    - json:spec/results/%{platform}_%{suite}.json
  inspec_tests:
    - name: RedHat 8 STIG v1r12
      path: .
  input_files:
    - kitchen.inputs.yml
  <% if ENV['INSPEC_CONTROL'] %>
  controls:
    - "<%= ENV['INSPEC_CONTROL'] %>"
  <% end %>
  load_plugins: true

suites:
  - name: vanilla
    provisioner:
      playbook: spec/ansible/roles/ansible-role-rhel-vanilla.yml
  - name: hardened
    provisioner:
      playbook: spec/ansible/roles/ansible-role-rhel-hardened.yml

Breakdown of the kitchen.yml file:

verifier:
  name: inspec
  sudo: true
  reporter:
    - cli
    - json:spec/results/%{platform}_%{suite}.json
  inspec_tests:
    - name: RedHat 8 STIG v1r12
      path: .
  input_files:
    - kitchen.inputs.yml
  <% if ENV['INSPEC_CONTROL'] %>
  controls:
    - "<%= ENV['INSPEC_CONTROL'] %>"
  <% end %>
  load_plugins: true

This first section configures the verifier, which is the tool that checks if your system is in the desired state. Here, it's using InSpec.

  • sudo: true means that InSpec will run with sudo privileges.
  • reporter specifies the formats in which the test results will be reported. Here, it's set to report in the command-line interface (cli) and in a JSON file (json:spec/results/%{platform}_%{suite}.json).
  • inspec_tests specifies the InSpec profiles to run. Here, it's running the "RedHat 8 STIG v1r12" profile located in the current directory (path: .).
  • input_files specifies files that contain input variables for the InSpec profile. Here, it's using the kitchen.inputs.yml file.
  • The controls section is dynamically set based on the INSPEC_CONTROL environment variable. If the variable is set, only the specified control will be run.
  • load_plugins: true means that InSpec will load any available plugins.
suites:
  - name: vanilla
    provisioner:
      playbook: spec/ansible/roles/ansible-role-rhel-vanilla.yml
  - name: hardened
    provisioner:
      playbook: spec/ansible/roles/ansible-role-rhel-hardened.yml

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

  • Each suite has a name and a provisioner.
  • The provisioner section specifies the Ansible playbook to use for the suite. Here, it's using the ansible-role-rhel-vanilla.yml playbook for the "vanilla" suite and the ansible-role-rhel-hardened.yml playbook for the "hardened" suite.

Environment Variables in kitchen.yml

  • INSPEC_CONTROL: This variable allows you to specify a single control to run during the bundle exec kitchen verify phase. This is particularly useful for testing or debugging a specific requirement.

Recap on Kitchen Stages

The workflow of Test Kitchen involves the following steps:

  1. Create: Test Kitchen uses the driver to create an instance of the platform.
  2. Converge: Test Kitchen uses the provisioner to apply the infrastructure code to the instance. In this case, it's using Ansible playbooks.
  3. Verify: Test Kitchen uses the verifier to check if the instance is in the desired state.
  4. Destroy: Test Kitchen uses the driver to destroy the instance after testing. This is not shown in your file.