A first look at Chef Automate 2.0

InSpec is an Open Source testing framework for infrastructure. It is a human-readable language for specifying compliance, security and other policy requirements as tests. When we integrate InSpec with Chef Automate (Chef’s continuous automation platform), there is a promise to gain greater control over the detection and correction of issues. Chef Automate provides analysis, reporting and visualisation based upon InSpec reports. Users can even download pre-packaged CIS benchmarks to use as is or to customise to their business or industry standards.

With tighter integration between IT Automation software and third-party tools, Chef Automate 2.0 was announced at the ChefConf in May this year. In this blog, I attempt to walk the reader through the installation of Chef Automate 2.0 and a basic use case. The reader should note that this is meant to be a bare-bone installation with the sole motive to try out the functionality. This is definitely *not* a production-ready installation.

Aim

The intention is to execute a compliance scan on a test node/VM based on a particular compliance profile. We would view the compliance reports on Chef Automate.

Assumptions

This article assumes that the reader is well-versed in:

• Basic Chef usage
• Inspec fundamentals

Automate 2.0 install

The installation documentation for Chef Automate 2.0 can be referred to at https://automate.chef.io/docs/install/

In this case, I attempted to install Chef Automate 2.0 on an EC2 instance where I had to fix a few ‘sysctl’ configs to get me up and working. Namely, the following configs:

sysctl --system
vm.max_map_count=262144
vm.dirty_expire_centisecs=20000

I then had to update the configurations (as per the installation document) in the ‘config.toml’ file to use the FQDN of my EC2 instance.

[global.v1]
  # The external fully qualified domain name.
  # When the application is deployed you should be able to access 'https://<fqdn>/'
  # to login.
  fqdn = "ec2-13-55-176-119.ap-southeast-2.compute.amazonaws.com"

Once Chef Automate is up and working, the UI can be accessed using the URL configured in the config.toml file.

The admin credentials are auto-generated and show up in the ‘automate-credentials’ toml file.

url = "https://ec2-13-55-176-119.ap-southeast-2.compute.amazonaws.com"
username = "admin"
password = "xxxx"

We could use these credentials to log in to the Chef Automate UI. When we login for the first time, we are prompted to provide the licence key or use a trial licence. I used a trial licence for this demo.

If we use a trial licence, we see a banner on the top half of the page indicating the time period left for our trial. For all practical purposes, the application functionality is not impacted by this for the duration of the trial licence (60 days).

Token creation

Once Chef Automate is up and working, we could create an ‘API’ token. This would come in handy at a later stage when we do the compliance scan. Navigate to ‘Admin’ → ‘API Tokens’ for doing this.

Compliance Profiles

Chef Compliance provides a number of profiles, but we’re expected to select the profile we intend to use. Use the ‘Asset Store’ → ‘Profiles’ option in the UI to select the profile you want to be made available for use. Once you click on the ‘Get’ button, the profile is downloaded and you can start using it.

In this example, we selected and downloaded the ‘DevSec Linux Security Baseline’ compliance profile.

Cookbook creation

Now that our Chef Automate 2.0 setup is up and working, let’s try and execute a compliance scan.

In this example, we would run a compliance scan on an EC2 instance (we would refer to it as a ‘test node’ in the rest of this article). In order to do that, we would need to create a Chef cookbook which would execute the scan on the test node and send the reports to Chef Automate. Luckily, such a cookbook exists – the ‘audit cookbook’. As per the best practices of Chef, we would create a ‘wrapper cookbook’ around the ‘audit cookbook’ so as to have our custom configurations and attributes.

The attributes file of my wrapper cookbook would have these parameters:

default['audit']['fetcher'] = 'chef-automate'
default['audit']['reporter'] = 'chef-automate'
default['audit']['server'] = 'https://ec2-13-55-176-119.ap-southeast-2.compute.amazonaws.com/api'
default['audit']['insecure'] = true
default['audit']['profiles'] = [
  {
    name: 'DevSec Linux Security Baseline',
    compliance: 'admin/linux-baseline'
  },
]

As we can observe from these attributes, we are:

• Setting the ‘server’ to the URL of our newly configured Chef Automate server
• Using an insecure connection (not recommended on a formal setup)
• Defining the Compliance profiles we intend to execute on the test node
• The ‘fetcher’ and ‘reporter’ attributes signify that we intend to use ‘Chef Automate’ as both the source for our compliance profile as well as to report the compliance results

I am assuming that the reader is able to create the wrapper cookbook with these overridden attributes and proceed to the next step.

Test Node Configs

Now that we have a Chef cookbook in place, let’s try and execute that cookbook on the test node. Ideally, we may want to use a Chef Server to ensure that the cookbook is pushed on to the test node and executed using a ‘chef-client’ run, but for simplicity, I am using ‘chef-solo’ for achieving the same purpose.

To use chef-solo, we:

• Installed chef on the test node using ‘yum install chef’
• Created a file – ‘solo.rb’ with the following configuration:

cookbook_path "/tmp/cookbooks"
log_location   STDOUT
node_name "test-node"
trusted_certs_dir "/etc/chef/trusted_certs"

data_collector.server_url "https://ec2-13-55-176-119.ap-southeast-2.compute.amazonaws.com/data-collector/v0/"
data_collector.token "UK2xRSfnXIhj7ILTgCatihtNJmg="
data_collector.mode ":both"

We can see that the data_collector.token field is populated with the API token which we created in an earlier step. The data_collector.server_url field is populated with the Chef Automate URL.

This also assumes that the Chef cookbook we created in the previous step has been transferred to the ‘/tmp/cookbooks’ directory on the test node.

• Created a file – ‘web.json’ with the following configuration:

{
  "run_list": [ "recipe[my_audit]" ]
}

‘my_audit’ refers to the name of the ‘wrapper cookbook’ we created in the previous step.

• Once these files are created, let’s execute the chef-solo command:

chef-solo -c solo.rb -j web.json

Compliance Report

When the chef-solo command executes successfully, we’re able to see the reports on Chef Automate. We could click through the reports to drill deeper into the cause of the compliance errors (if any).

Next steps

Now that we’re warmed up with Chef Automate 2.0, we could proceed with the next steps to:

• Use a Chef Server to push cookbooks on to a test-node and to run a compliance scan using a chef-client execution
• Correct the compliance errors using Chef and generate a report again to see if the compliance errors are fixed. This is also referred to as a ‘detect-correct-verify’ cycle
• Setting up SSL Configurations and making this installation a bit more formal
• Use the Chef Compliance APIs, instead of the UI

With a bit of luck, we could tackle them in our next blog!

• Twitter
• Linkedin
• Email