InSpec 2.0 Release!

Chef Release Announcements
1

We’re so thrilled to release InSpec 2.0 to our amazing community. This is our first major version update in over a year so we’d like to inform you of the great improvements and impactful changes this new version brings.

New in 2.0: AWS and Azure Cloud Resources

InSpec now supports testing configurations for cloud provider platforms such as AWS or Azure. There are 30 new resources, such as aws_s3_bucket and azure_virtual_machine, to get you started writing compliance rules!

New in 2.0: Unique Exit Codes

InSpec will now exit with a unique exit code depending on the status of the controls and tests that were executed. The new exit codes are:

  • 0: Successful run and no test failures found.
  • 100: Successful run, test failures were found.
  • 101: Successful run, no test failures, but test skips were found.
  • anything else: An error occurred while running InSpec, such as a syntax issue, or a failure to find the specified profile.

This will make it easier to insert InSpec into a CI/CD pipeline and, for example, let you choose whether test skips are worthy of halting your pipeline.

New in 2.0: http resource uses remote worker by default on remote targets

In 1.x, we introduced the ability to enable a “remote worker” when using the http resource when scanning a remote machine. However, this was opt-in behavior as many users were relying on the HTTP calls originating from the host on which InSpec was running.

This behavior is no longer opt-in and now matches the expected behavior of all other InSpec resources: when scanning a remote machine, the tests should originate from the machine being scanned.

Example:

# 1.X
describe http('http://www.example.com', enable_remote_worker: true) do
  its('body') { should cmp 'awesome' } 
end

# 2.0
describe http('http://www.example.com') do
  its('body') { should cmp 'awesome' } 
end

Breaking Change: Values in time fields are now in RFC3339 format

If you use the json reporter in your InSpec runs, the values in time fields are now formatted using the well-known RFC3339 format (example: 2018-01-23T16:11:18-05:00) instead of Ruby’s string representation of a Time object (example: 2018-01-23 16:11:18 -0500).

Breaking Change: Removal of the top-level “controls” field in json reports

If you use the json reporter in your InSpec runs, the top-level controls field has been removed. All the data is still available within the controls field found within each profile object in the report.

Breaking Change: ‘/’ characters not permitted in profile names

In order to standardize a naming convention for profiles stored in Chef Automate and avoid confusion when profiles are stored in other directory-based locations, the / character is no longer permitted in a profile’s name (as defined in the profile’s inspec.yml file).

Breaking Change: OS names are always lowercase

In InSpec 1.x, OS names were potentially returns in mixed case, such as Windows Server 2008 R2 and therefore, when used in profiles, would need to match that case. For example:

only_if { os.name == 'Windows Server 2008 R2' }

Beginning with InSpec v1.49.2, OS names have been standardized as all lowercase when underscores instead of spaces. For example, Windows Server 2008 R2 becomes windows_server_2008_r2. InSpec v1.49.2 and earlier performed any translation necessary in profiles to ensure the comparison would work and a warning was emitted to inform users of the change.

This translation and warning has been removed and any profile performing a comparison against the OS name will need to be updated to use the new lowercase format.

Breaking Change: Missing requirements for resources now triggers a failure instead of a skip

In order for many resources to execute tests properly, certain requirements must exist. For example, to test a configuration setting of an nginx configuration value, the nginx configuration file must exist. Currently, many resources will simply “skip” the test if the requirement is not met. In principal, this is suboptimal as InSpec was not able to successfully execute the test as written. Therefore, resources have been updated to fail instead of skip when a requirement is not met.

Users wishing to retain the existing behavior can use an only_if condition to skip the control based on a particular requirement. For example:

conf_file = '/var/opt/mysite/etc/nginx.conf'
control 'nginx-1' do
  describe nginx_conf(conf_file) do
    its('some_setting') { should cmp 1 }
  end

  only_if { file(conf_file).exist? }
end

Removed Deprecations

The following features were deprecated in InSpec 1.x and are now no longer available in InSpec 2.0:

  • The inspec compliance login_automate command has been removed. Use inspec compliance login instead.
  • The assignment_re option for the SimpleConfig utility, used by the parse_config and parse_config_file resources, is removed. Use assignment_regex instead.
  • The key_vals option for the SimpleConfig utility, used by the parse_config and parse_config_file resources, is removed. Use key_values instead.
  • The --cache flag for inspec exec has been removed. Use --vendor-cache instead.
  • The auditd_rules resource has been removed. Use the auditd or auditd_conf resource instead.
  • The following properties on the passwd resource have been removed:
    • count (use entries.length instead)
    • usernames (use users instead)
    • username (use users instead)
    • uid (use uids instead)

Additionally, the following global matchers have been removed:

  • contain_legacy_plus (this was intended to be removed in InSpec 1.0 but was missed)
  • contain_match (this was intended to be removed in InSpec 1.0 but was missed)
  • contain_duplicates (this was intended to be removed in InSpec 1.0 but was missed)
  • with_version
  • belong_to_group
  • belong_to_primary_group
  • contain

Many of these matchers has a more appropriate resource-specific property that should be used instead. For example, in the package resource, instead of using with_version, a test can be written as: its('version') { should cmp '1.2.3' }

For more information about InSpec 2.0 please visit our website at https://www.inspec.io/

You can find v2.0.17 at downloads.chef.io, RubyGems, Habitat Builder, and Docker Hub.

Thanks,
Jared