Understanding InSpec Profile Inheritance
// Chef Blog
Engineers sometimes use the phrase DRY – Don't Repeat Yourself. It's commonly used when writing or reviewing code that is repetitive. The usual solution is to take the repetitious code and turn it into something that can be reused.
It's really easy to fall into the "repeat yourself" trap, even with a tool like InSpec. InSpec Profiles contain some number of controls and tests that describe the compliance status of a host or system. It's likely that all hosts in a fleet need to be tested against the same compliance rules. But what if one host has a legitimate reason to fail a particular test? Or what if a test for a group of hosts is considered a lower severity failure than a different group of hosts? Don't fork/copy that profile just yet!
Using Profile Inheritance
In addition to its own controls, an InSpec profile can bring in the controls from another InSpec profile. Additionally, when inheriting the controls of another profile, a profile can skip or even modify those included controls.
When a profile includes controls from another profile, it is usually referred to as a "meta profile" or a "profile overlay." Those of us with Chef background sometimes call it a "wrapper profile," a loving reference to the "wrapper cookbook" pattern so many of our Chef community members are fond of.
Defining the Dependencies
Before a profile can use controls from another profile, the to-be-included profile needs to be specified in the including profile's
inspec.yml file in the
depends section. For each profile to be included, a location for the profile from where to be fetched and a name for the profile should be included. For example:
depends: - name: linux-baseline url: https://github.com/dev-sec/linux-baseline/archive/master.tar.gz - name: ssh-baseline url: https://github.com/dev-sec/ssh-baseline/archive/master.tar.gz
Once defined in the
inspec.yml, controls from the included profiles can be used! Let's look at some examples.
Including All Controls from a Profile
include_controls command in a profile, all controls from the named profile will be executed every time the including profile is executed.
In the example above, every time
my-app-profile is executed, all the controls from
my-baseline are also executed. Therefore, the following controls would be executed:
This is a great reminder that having a good naming convention for your controls is helpful to avoid confusion when
including controls from other profiles!
Skipping a Control from a Profile
What if one of the controls from the included profile does not apply to your environment? Luckily, it is not necessary to maintain a slightly-modified copy of the included profile just to delete a control. The
skip_control command tells InSpec to not run a particular control.
In the above example, all controls from
my-baseline profile will be executed every time
my-app-profile is executed except for control
baseline-2 from the
Modifying a Control
Let's say a particular control from an included profile should still be run, but the impact isn't appropriate? Perhaps the test should still run, but if it fails, it should be treated as low severity instead of high severity?
When a control is included, it can also be modified!
In the above example, all controls from
my-baseline are executed along with all the controls from the including profile,
my-app-profile. However, should control
baseline-1 fail, it will be raised with an impact of
0.5 instead of the originally-intended impact of
Selectively Including Controls from a Profile
If there are only a handful of controls that should be executed from an included profile, it's not necessary to skip all the unneeded controls, or worse, copy/paste those controls bit-for-bit into your profile. Instead, use the
my-app-profile is executed, in addition to its own controls, it will run only the controls specified in the
require_controls block. In the case, the following controls would be executed:
baseline-5 would not be run, just as if they were manually skipped. This method of including specific controls ensures only the controls specified are executed; if new controls are added to a later version of
my-baseline, they would not be run.
And, just the way its possible to modify controls when using
include_controls, controls can be modified as well.
As with the prior example, only
baseline-4 are executed, but if
baseline-2 fails, it will report with an impact of
0.5 instead of the originally-intended
An Example Profile
I have published a real InSpec profile that uses the above tips and tricks. Look at the
controls/controls_from_other_profiles.rb control file for similar examples to those I've provided above in this post.
Let's go reuse!
Despite its somewhat-scary name, profile inheritance isn't scary at all! In fact, it will help keep profile sprawl to a minimum and help promote profile reuse and creation of reusable profiles.
Do you have more questions? Don't be shy! Swing by the
#inspec channel of the Chef Community Slack and let us know how we can help.
Read in my feedly
Sent from my iPhone