4. Test your Test Environment

Learning Objectives

• Understand the different testing environments available
• Learn how to use Test Kitchen commands
• Execute your first test run
• Troubleshoot common testing issues

Introduction

Before diving into testing your security profiles, let's understand the testing environment and tools we'll be using. This module will guide you through the Test Kitchen framework and help you run your first test.

Available Testing Environments

You have four options for setting up your testing environment:

📦 Docker Testing

• Uses containers for lightweight, fast testing
• Perfect for local development
• Minimal resource requirements

🌥️ AWS VPC Testing

• Uses AWS infrastructure
• Ideal for production-like environments
• Requires AWS credentials

🖥️ Vagrant Testing

• Uses virtual machines locally
• Great for isolated testing
• Supports multiple OS environments

💻 Local Testing

• Uses your local machine
• Fastest to set up
• Best for initial development

Test Kitchen Lifecycle

Test Kitchen follows a four-stage lifecycle:

1. Create 🏗️

   • Sets up testing instance
   • Prepares login credentials
   • Initializes testing environment

2. Converge 🔄

   • Runs configuration management
   • Applies system settings
   • Prepares system state

3. Verify ✅

   • Executes InSpec profile
   • Runs security tests
   • Reports results

4. Destroy 🗑️

   • Cleans up resources
   • Removes test instances
   • Resets environment

Running Your First Test

Prerequisites

Before starting, ensure you have:

• Test Kitchen installed
• Proper environment variables set
• Required credentials configured

Basic Commands

For each of these examples, you need to update the KITCHEN_LOCAL_YAML environment variable to point to the correct kitchen.<TEST-TARGET>.yaml file. Ensure that any required supporting environment settings, environment variables, profiles, etc., are in place. See Environment Variables and Testing Target Environments for more information.

Learn more about the Test Kitchen project at: kitchen.ci

Kitchen Stages

Test Kitchen has four major steps: create, converge, verify, and destroy. Use these stages to create, configure, run tests, and destroy your testing target. When starting your testing, it's useful to run each of these in turn to ensure your environment, Test Kitchen, and credentials are set up and working correctly.

1. create:
   The create stage sets up your testing instance and prepares the necessary login credentials and other components so you can use your testing target.
2. converge:
   The converge stage runs the provisioner of the Test Kitchen suite - the configuration management code set up in the test suite. This could be any configuration management script, such as Ansible, Chef, Puppet, Terraform, Shell, etc., that you and your team use.
3. verify:
   The verify stage runs the actual InSpec profile against your testing target. Test Kitchen supports multiple testing frameworks, which are well documented on the project website.
4. destroy:
   The destroy stage tears down your test target - like an EC2 instance, Docker container, or Vagrant Box.

During your testing, you will use each of these steps to run the full profile, run individual controls (using the INSPEC_CONTROL environment variable), and manage your test instances. You will also use other Test Kitchen commands, such as login, test, and others, which are documented on the Test Kitchen Project page.

You can also isolate which of the 'target suites' - either vanilla or hardened in our case - to run by appending either hardened or vanilla to the end of your Test Kitchen command. For example, bundle exec kitchen verify will run the Test Kitchen stages all the way through verify on both the hardened and vanilla suites. However, if you say, bundle exec kitchen verify vanilla, it will only run it on the vanilla test target.

Useful Test Kitchen Commands

• login: Allows you to easily log in using the credentials created when you ran bundle exec kitchen create.
• test: Runs all the Test Kitchen stages starting with create through destroy to easily allow you to go through a full clean test run.