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 automatically and merge them with the settings 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 9 STIG v1r2
      path: .
  input_files:
    - kitchen.inputs.yml
  <% if ENV['INSPEC_CONTROL'] %>
  controls:
    - "<%= ENV['INSPEC_CONTROL'] %>"
  <% end %>
  load_plugins: true
  env_vars:
    - "CHEF_LICENSE=<%= ENV['CHEF_LICENSE'] %>"

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

transport:
  max_ssh_sessions: 6

Breakdown of the kitchen.yml file

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

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). Note that variables will be templated into this filename by Kitchen to help you differentiate between the different testing configurations you're iterating over.
• inspec_tests specifies the InSpec profiles to run. Here, it's running the "RedHat 9 STIG v1r2" 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.

transport:
  max_ssh_sessions: 6

The last section allows you to configure attributes of the transport. In this case, we're setting the maximum number of parallel SSH sessions.

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.