No description
Find a file
Dominik Richter 6e1ffb4890 Merge pull request #1204 from chef/ap/cmp-desc
cmp code_desc missing operation and expected valid
2016-10-10 06:12:37 -07:00
bin move force encoding to binary only, so that it does not affect the use of inspec in lib mode 2016-09-13 16:18:40 +02:00
docs Merge pull request #1179 from davidwrede/doc_edits 2016-09-30 15:33:21 +02:00
examples Remove pre-1.0 warning from meta-profile 2016-10-02 18:06:07 +02:00
lib fix cmp code description 2016-10-10 05:40:22 -07:00
omnibus update omnibus images 2016-09-26 15:29:27 +02:00
tasks add sanity checks for docs and middleman build 2016-09-28 12:10:54 -04:00
test add tests for cmp output 2016-10-10 05:40:22 -07:00
www re-generate responses 2016-10-06 13:32:53 +02:00
.gitignore Ignore lockfiles in example profiles 2016-09-28 13:49:06 +01:00
.kitchen.chef.yml fix integration tests for suse 11 2016-09-05 11:22:52 +02:00
.kitchen.ec2.yml harmonize cookbooks for integration tests, update docs, remove i386 in vagrant 2016-08-05 10:52:03 +02:00
.kitchen.vagrant.yml harmonize cookbooks for integration tests, update docs, remove i386 in vagrant 2016-08-05 10:52:03 +02:00
.kitchen.yml add fedora 23 & 24 to kitchen integration tests 2016-08-05 10:52:03 +02:00
.rubocop.yml added hpux user and package resource support 2016-04-21 14:01:56 +05:30
.travis.yml move inquirer to deploy 2016-09-27 14:23:32 -04:00
appveyor.yml move inquirer to deploy 2016-09-27 14:23:32 -04:00
Berksfile run integration tests in docker 2016-05-16 18:25:17 +02:00
CHANGELOG.md 1.1.0 2016-10-05 15:28:22 +02:00
CONTRIBUTING.md update issue template and add contributing.md 2016-04-06 12:28:43 +02:00
Dockerfile rake release_docker + smaller image builds 2016-05-13 12:59:33 +02:00
Gemfile move inquirer to deploy 2016-09-27 14:23:32 -04:00
inspec.gemspec ssl resource to use inspec.backend.hostname and require train 0.19.1 2016-09-16 10:41:22 +01:00
ISSUE_TEMPLATE.md update issue template and add contributing.md 2016-04-06 12:28:43 +02:00
LICENSE license belongs in LICENSE 2015-11-03 10:04:16 -08:00
MAINTAINERS.md Update links in the maintainers docs 2016-08-19 20:14:03 +02:00
MAINTAINERS.toml Update links in the maintainers docs 2016-08-19 20:14:03 +02:00
Rakefile add build tasks for www 2016-09-22 23:51:30 +02:00
README.md Add shell options 2016-09-30 15:18:14 -04:00

InSpec: Inspect Your Infrastructure

Join the chat at https://gitter.im/chef/inspec Build Status Master Build Status Master

InSpec is an open-source testing framework for infrastructure with a human- and machine-readable language for specifying compliance, security and policy requirements.

# Disallow insecure protocols by testing

describe package('telnetd') do
  it { should_not be_installed }
end

describe inetd_conf do
  its("telnet") { should eq nil }
end

InSpec makes it easy to run your tests wherever you need. More options are found in our CLI docs.

# run test locally
inspec exec test.rb

# run test on remote host on SSH
inspec exec test.rb -t ssh://user@hostname -i /path/to/key

# run test on remote windows host on WinRM
inspec exec test.rb -t winrm://Administrator@windowshost --password 'your-password'

# run test on docker container
inspec exec test.rb -t docker://container_id

Features

  • Built-in Compliance: Compliance no longer occurs at the end of the release cycle
  • Targeted Tests: InSpec writes tests that specifically target compliance issues
  • Metadata: Includes the metadata required by security and compliance pros
  • Easy Testing: Includes a command-line interface to run tests quickly

Installation

InSpec requires Ruby ( >1.9 ).

Install it via rubygems.org

When installing from source, gem dependencies may require ruby build tools to be installed.

For CentOS/RedHat/Fedora:

yum -y install ruby ruby-devel make gcc

For Ubuntu:

apt-get -y install ruby ruby-dev gcc make

To install inspec from rubygems:

gem install inspec

Usage via Docker

Download the image and define an alias for convenience:

docker pull chef/inspec
alias inspec='docker run -it --rm -v $(pwd):/share chef/inspec'

If you call inspec from cli, it automatically mounts the current directory into the work directory. Therefore you can easily use local tests and key files. Note: Only files in the current directory are available to the container.

$ ls -1
vagrant
test.rb


$ inspec exec test.rb -t ssh://root@192.168.64.2:11022 -i vagrant
..

Finished in 0.04321 seconds (files took 0.54917 seconds to load)
2 examples, 0 failures

Install it from source

That requires bundler:

bundle install
bundle exec bin/inspec help

To install it as a gem locally, run:

gem build inspec.gemspec
gem install inspec-*.gem

On Windows, you need to install Ruby with Ruby Development Kit to build dependencies with its native extensions.

Run InSpec

You should now be able to run:

$ inspec --help
Commands:
  inspec archive PATH                # archive a profile to tar.gz (default) ...
  inspec check PATH                  # verify all tests at the specified PATH
  inspec compliance SUBCOMMAND ...   # Chef Compliance commands
  inspec detect                      # detect the target OS
  inspec exec PATH(S)                # run all test files at the specified PATH.
  inspec help [COMMAND]              # Describe available commands or one spe...
  inspec init TEMPLATE ...           # Scaffolds a new project
  inspec json PATH                   # read all tests in PATH and generate a ...
  inspec shell                       # open an interactive debugging shell
  inspec supermarket SUBCOMMAND ...  # Supermarket commands
  inspec version                     # prints the version of this tool

Options:
  [--diagnose], [--no-diagnose]  # Show diagnostics (versions, configurations)

Examples

  • Only accept requests on secure ports - This test ensures that a web server is only listening on well-secured ports.
describe port(80) do
  it { should_not be_listening }
end

describe port(443) do
  it { should be_listening }
  its('protocols') {should include 'tcp'}
end
  • Use approved strong ciphers - This test ensures that only enterprise-compliant ciphers are used for SSH servers.
describe sshd_config do
   its('Ciphers') { should eq('chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr') }
end
  • Test your kitchen.yml file to verify that only Vagrant is configured as the driver.
describe yaml('.kitchen.yml') do
  its('driver.name') { should eq('vagrant') }
end

Also have a look at our examples for:

Or tests: Testing for a OR b

  • Using describe.one, you can test for a or b. The control will be marked as passing if EITHER condition is met.
control 'or-test' do
  impact 1.0
  title 'This is a OR test'
  describe.one do
    describe ssh_config do
      its('Protocol') { should eq('3') }
    end
    describe ssh_config do
      its('Protocol') { should eq('2') }
    end
  end
end

Command Line Usage

exec

Run tests against different targets:

# run test locally
inspec exec test.rb

# run test on remote host on SSH
inspec exec test.rb -t ssh://user@hostname

# run test on remote windows host on WinRM
inspec exec test.rb -t winrm://Administrator@windowshost --password 'your-password'

# run test on docker container
inspec exec test.rb -t docker://container_id

# run with sudo
inspec exec test.rb --sudo [--sudo-password ...] [--sudo-options ...] [--sudo_command ...]

# run in a subshell
inspec exec test.rb --shell [--shell-options ...] [--shell-command ...]

detect

Verify your configuration and detect

id=$( docker run -dti ubuntu:14.04 /bin/bash )
inspec detect -t docker://$id

Which will provide you with:

{"family":"ubuntu","release":"14.04","arch":null}

Supported OS

Remote Targets

Platform Versions Architectures
AIX 6.1, 7.1, 7.2 ppc64
CentOS 5, 6, 7 i386, x86_64
Debian 7, 8 i386, x86_64
FreeBSD 9, 10 i386, amd64
Mac OS X 10.9, 10.10, 10.11 x86_64
Oracle Enterprise Linux 5, 6, 7 i386, x86_64
Red Hat Enterprise Linux 5, 6, 7 i386, x86_64
Solaris 10, 11 sparc, x86
Windows 7, 8, 8.1, 2008*, 2008R2* , 2012, 2012R2 x86, x86_64
Ubuntu Linux x86, x86_64
SUSE Linux Enterprise Server 11, 12 x86_64
Scientific Linux 5.x, 6.x and 7.x i386, x86_64
Fedora x86_64
OpenSUSE 13.1/13.2/42.1 x86_64
OmniOS x86_64
Gentoo Linux x86_64
Arch Linux x86_64
HP-UX 11.31 ia64
  • For Windows 2008 and 2008 R2 an updated Powershell (Windows Management Framework 5.0) is required.

In addition, runtime support is provided for:

Platform Versions
Debian 8
RHEL 6, 7
Ubuntu 12.04+
Windows 7+
Windows 2012+

Documentation

Documentation

Blogs:

Podcasts:

Share your Profiles

You may share your InSpec Profiles in the Tools & Plugins section of the Chef Supermarket. Sign in and add the details of your profile.

You may also browse the Supermarket for shared Compliance Profiles.

Kudos

InSpec is inspired by the wonderful Serverspec project. Kudos to mizzy and all contributors!

Contribute

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request

The InSpec community and maintainers are very active and helpful. This project benefits greatly from this activity.

InSpec health

Testing InSpec

We perform unit, resource and integration tests.

  • unit tests ensure the intended behaviour of the implementation
  • resource tests run against docker containers
  • integration tests run against VMs via test-kitchen and kitchen-inspec

Unit tests

bundle exec rake test

If you like to run only one test, use

bundle exec ruby -W -Ilib:test test/unit/resources/user_test.rb

Resource tests

Resource tests make sure the backend execution layer behaves as expected. These tests will take a while, as a lot of different operating systems and configurations are being tested.

You will require:

  • docker

Run resource tests with

bundle exec rake test:resources config=test/test.yaml
bundle exec rake test:resources config=test/test-extra.yaml

Integration tests

These tests download various virtual machines, to ensure InSpec is working as expected across different operating systems.

You will require:

  • vagrant with virtualbox
  • test-kitchen

Run integration tests with vagrant:

KITCHEN_YAML=.kitchen.vagrant.yml bundle exec kitchen test

Run integration tests with AWS EC2:

export AWS_ACCESS_KEY_ID=enteryouryourkey
export AWS_SECRET_ACCESS_KEY=enteryoursecreykey
export AWS_KEYPAIR_NAME=enteryoursshkeyid
export EC2_SSH_KEY_PATH=~/.ssh/id_aws.pem
KITCHEN_YAML=.kitchen.ec2.yml bundle exec kitchen test

In addition you may need to add your ssh key to .kitchen.ec2.yml

transport:
  ssh_key: /Users/chartmann/aws/aws_chartmann.pem
  username: ec2-user

License

Author: Dominik Richter (drichter@chef.io)
Author: Christoph Hartmann (chartmann@chef.io)
Copyright: Copyright (c) 2015 Chef Software Inc.
Copyright: Copyright (c) 2015 Vulcano Security GmbH.
License: Apache License, Version 2.0

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.