Posts on Cloud,DevOps, Citrix,VMware and others. Also tracking my Continuous learning from Wintel to open source and development.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.

Wednesday, May 6, 2015

Chef Audit Mode Introduction [feedly]

I have been working with the audit mode feature introduced in Chef version 12.1.0 – previously announced was the audit-cis cookbook. Audit mode allows users to write custom rules (controls) in Chef recipes using new DSL helpers. In his ChefConf 2015 talk, "Compliance At Velocity," James Casey goes into more of the background and reasoning for this. For now, I wanted to share a few tips with users who may be trying out this feature, too.

This is the generated .kitchen.yml with client_rb added to the provisioner config to enable audit mode. Note that we must use the Ruby symbol syntax, :audit_only. The valid values for audit_mode are :enabled, :audit_only and :disabled. This will be translated to an actual Ruby symbol in the generated config file (/tmp/kitchen/client.rb):

audit_mode :audit_only

Next, let's write a control rule to test. Since we're using the default .kitchen.yml, which includes Ubuntu 12.04 and uses SSH to connect, we can assume that SSH is running, so port 22 is listening. The following control asserts this is true.

control_group 'Blog Post Examples' do control 'SSH' do it 'should be listening on port 22' do expect(port(22)).to be_listening end end end

Now run kitchen converge ubuntu to run Chef, but not tear down the VM afterward – we'll use it again for another example. Here's the audit phase output from the Chef run:

Cool! So we have asserted that the node complies with this control by default. But what does a failing control look like? Let's write one. Since we're working with SSH already, let's use the SSHd configuration. By default in the Vagrant base box we're using, root login is permitted, so this value is present:

PermitRootLogin yes

However, our security policy mandates that we set this to no, and we want to audit that.

control_group 'Blog Post Examples' do control 'SSH' do it 'should be listening on port 22' do expect(port(22)).to be_listening end it 'disables root logins over ssh' do expect(file('/etc/ssh/sshd_config').content).to contain('PermitRootLogin no') end end end

When we have a failure, we'll have contextual information about the failure, including the line number in the recipe where it was found, and a stack trace (cut from the output here), in case more information is required for debugging. To fix the test, we can simply edit the config file to have the desired setting, or we can manage the file with Chef to set the value accordingly. Either way, after updating the file, the validation will pass, and all will be well.

We can put as many control_group and control blocks with the it validation rules as required to audit our policy. If we have many validations, it can be difficult to follow with all the output if there are failures. Chef's audit mode is based on Serverspec, which is based on RSpec. We can use the filter_tag configuration feature of RSpec to only run the control blocks or it statements that we're interested in debugging. To do this, we need an RSpec.configuration block within the control_group – due to the way that audit mode is implemented, we can't do it outside of control_group.

For example, we could debug our root login configuration:

control_group 'Blog Post Examples' do ::RSpec.configure do |c| c.filter_run focus: true end control 'SSH' do it 'should be listening on port 22' do expect(port(22)).to be_listening end it 'disables root logins over ssh', focus: true do expect(file('/etc/ssh/sshd_config').content).to contain('PermitRootLogin no') end end end

The key here is to pass the argument focus: true (or if you like hash rockets, :focus => true) on the it block. This could also be used on a control block:

control 'SSH', focus: true do it 'does stuff...' end

Then, when running kitchen converge ubuntu, we see only that validation:

This example is simple enough that using focus isn't necessary, but if we were implementing audit mode checks for our entire security policy, that could be dozens or even hundreds of controls.

While audit mode is still in development as a feature, we think that it is highly valuable to organizations that need to ensure their systems are compliant with varying types of audit requirements. Also, because audit mode can be run on its own without converging resources in Chef recipes, it's great for assessing existing system's state before starting to implement Chef.