inspec 2.3.10 → 2.3.23

data/docs/style.md

@@ -1,178 +0,0 @@
-# InSpec profile style guide
-
-This is a set of recommended InSpec rules you should use when writing controls.
-
-## Control files
-
-### 1. All controls should be located in the "controls" directory and end in ".rb"
-
-Reason: Most syntax highlighters will render InSpec files correctly across a wide list of tools.
-
-Avoid: `controls/ssh_config`
-Use: `controls/ssh_config.rb`
-
-Avoid: `controls/ssh/config.rb`
-Use: `controls/ssh_config.rb`
-
-### 2. Avoid using "controls" or "control" in the name of your control files
-
-Reason: Using `controls` in the filename again duplicates it and creates unnecessary clutter when reading it. Keep the names short and concise.
-
-Avoid: `controls/ssh_controls.rb`
-Use: `controls/ssh.rb`
-
-
-## Code style
-
-### 3. Avoid unnecessary parentheses in matchers
-
-Adding additional parentheses is not required and provides more readability if it is not used:
-
-Avoid: `it { should eq(value) }`
-Use: `it { should eq value }`
-
-The exception are matchers that require additional arguments or named arguments.
-
-
-## Controls
-
-### 4. Do not wrap controls in conditional statements
-
-Reason: This will create dynamic profiles whose controls depend on the execution. The problem here is that we cannot render the profile or provide its information before scanning a system. We want to be able to inform users of the contents of their profiles before they run them. It is valid to skip controls that are not necessary for a system, as long as you do it via `only_if` conditions. Ruby's internal conditionals will hide parts of the profile to static analysis and should thus be avoided.
-
-Avoid:
-```ruby
-if package('..').installed?
-  control "package-test1" do
-    ..
-  end
-end
-```
-
-Use:
-```ruby
-control "package-test1" do
-  only_if { package('..').installed? }
-end
-```
-
-Avoid:
-```ruby
-case inspec.platform.name
-when /centos/
-  include_controls 'centos-profile'
-...
-```
-
-Use: The `supports` attribute in `inspec.yml` files of the profile you want to include:
-
-```ruby
-supports:
-- platform-name: centos
-```
-
-Now whenever you run the base profile you can just `include_controls 'centos-profile'`.
-It will only run the included profiles is the platform matches the supported platform.
-
-
-### 5. Do not include dynamic elements in the control IDs
-
-Reason: Control IDs are used to map test results to the tests and profiles. Dynamic control IDs make it impossible to map results back, since the identifier which connects tests and results may change in the process.
-
-Avoid:
-```ruby
-control "test-file-#{name}" do
-  ..
-end
-```
-
-Use:
-```ruby
-control "test-all-files" do
-  ..
-end
-```
-
-Sometimes you may create controls from a static list of elements. If this list stays the same no matter what system is scanned, it may be ok to do so and use it as a generator for static controls.
-
-
-### 6. Avoid Ruby system calls
-
-Reason: Ruby code is executed on the system that runs InSpec. This allows
-InSpec to work without Ruby and rubygems being required on remote
-targets (servers or containers). System calls are often used to interact with
-the local OS or remote endpoints from a local installation.
-InSpec tests, however, are designed to be universally executable on all
-types of runtimes, including local and remote execution. We want to give
-users the ability to take an OS profile and execute it remotely or locally.
-
-**Avoid shelling out**
-
-Avoid: `` `ls``\`
-Avoid: `system("ls")`
-Avoid: `IO.popen("ls")`
-Use: `command("ls")` or `powershell("..")`
-
-Ruby's command executors will only run localy. Imagine a test like this:
-
-```ruby
-describe `whoami` do
-  it { should eq "bob\n" }
-end
-```
-
-If you run this test on your local system and happen to be using Bob's account
-it will succeed. But if you were to run it against `--target alice@remote-host.com`
-it will still report that the user is bob instead of alice.
-
-Instead, do this:
-
-```ruby
-describe command('whoami') do
-  its('stdout') { should eq "bob\n" }
-end
-```
-
-If the profile is pointed to a remote endpoint using the `command` resource
-will run it on the remote OS.
-
-**Avoid Ruby IO on files**
-
-Avoid: `File.new("filename").read`
-Avoid: `File.read("filename")`
-Avoid: `IO.read("filename")`
-Use: `file("filename")`
-
-Similar to the command interactions these files will only be read localy
-with Ruby's internal calls. If you run this test against a remote target it won't
-read the file from the remote endpoint, but from the local OS instead.
-Use the `file` resource to read files on the target system.
-
-In general, try to avoid Ruby's IO calls from within InSpec controls and
-use InSpec resources instead.
-
-
-### 7. Avoid Ruby gem dependencies in controls
-
-In addition to avoiding system-level gems and modules you should also limit
-the use of external dependencies to resource packs or plugins. Gems need to be
-resolved, installed, vendored, and protected from conflicts. We aim to avoid
-exposing this complexity to users of InSpec, to make it a great tool even if
-you are not a developer.
-
-Developers may still use external gem dependencies but should vendor it
-with their plugins or resource packs.
-
-
-### 8. Avoid debugging calls (in production)
-
-Reason: One of the best way to develop and explore tests is the interactive debugging shell `pry` (see the section on "Interactive Debugging with Pry" at the end of this page). However, after you finish your profile make sure you have no interactive statements included anymore. Sometimes interactive calls are hidden behind conditionals (`if` statements) that are harder to reach. These calls can easily cause trouble when an automated profiles runs into an interactive `pry` call that stops the execution and waits for user input.
-
-Avoid: `binding.pry` in production profiles
-Use: Use debugging calls during development only
-
-Also you may find it helpful to use the inspec logging interface:
-
-```ruby
-Inspec::Log.info('Hi')
-```

data/examples/README.md

@@ -1,8 +0,0 @@
-# InSpec examples
-
-This directory contains multiple examples that explain the usage of the InSpec:
-
- - `kitchen-chef` Test-Kitchen with [Chef and InSpec](kitchen-chef/README.md)
- - `kitchen-puppet` Test-Kitchen with [Puppet and InSpec](kitchen-puppet/README.md)
- - `kitchen-ansible` Test-Kitchen with [Ansible and InSpec](kitchen-ansible/README.md)
- - `profile` Example of an InSpec profile

data/examples/custom-resource/README.md

@@ -1,3 +0,0 @@
-# Example Custom Resource Profile
-
-This example shows the implementation of an InSpec profile with custom resources.

data/examples/custom-resource/controls/example.rb

@@ -1,7 +0,0 @@
-# encoding: utf-8
-
-describe gordon do
-  its('crime_rate') { should be < 5 }
-  it { should have_a_fabulous_mustache }
-end
-

data/examples/custom-resource/inspec.yml

@@ -1,8 +0,0 @@
-name: custom_resource_example
-title: InSpec Profile
-maintainer: The Authors
-copyright: The Authors
-copyright_email: you@example.com
-license: Apache-2.0
-summary: An InSpec Compliance Profile
-version: 0.1.0

data/examples/custom-resource/libraries/batsignal.rb

@@ -1,20 +0,0 @@
-class Batsignal < Inspec.resource(1)
-  name 'batsignal'
-
-  example "
-      describe batsignal do
-        its('number_of_sightings)') { should eq '4' }
-      end
-  "
-
-  def number_of_sightings
-    local_command_call
-  end
-
-  private
-
-  def local_command_call
-    # call out to a core resource
-    inspec.command('echo 4').stdout.to_i
-  end
-end

data/examples/custom-resource/libraries/gordon.rb

@@ -1,21 +0,0 @@
-class Gordon < Inspec.resource(1)
-  name 'gordon'
-
-  example "
-    describe gordon do
-      its('crime_rate') { should be < 2 }
-      it { should have_a_fabulous_mustache }
-    end
-  "
-
-  def crime_rate
-    # call out ot another custom resource
-    inspec.batsignal.number_of_sightings
-  end
-
-  def has_a_fabulous_mustache?
-    # always true
-    true
-  end
-end
-

data/examples/inheritance/README.md

@@ -1,65 +0,0 @@
-# Example InSpec Profile
-
-This example shows the use of InSpec [profile](../../docs/profiles.rst) inheritance.
-
-## Verify a profile
-
-InSpec ships with built-in features to verify a profile structure.
-
-```bash
-$ inspec check examples/inheritance
-```
-
-## Execute a profile
-
-To run a profile on a local machine use `inspec exec /path/to/profile`. All dependencies are automatically resolved.
-
-```bash
-$ inspec exec examples/inheritance
-```
-
-## Set attributes for dependent profiles
-
-Without setting attributes, an `inspec exec` would return the following:
-
-```
-$ inspec git:(master) ✗ b inspec exec examples/inheritance
-
-Profile: InSpec example inheritance (inheritance)
-Version: 1.0.0
-Target:  local://
-
-
-  ○  gordon-1.0: Verify the version number of Gordon (1 skipped)
-     ○  Can't find file "/tmp/gordon/config.yaml"
-     ✔  File  content should match nil
-  ✔  ssh-1: Allow only SSH Protocol 2
-     ✔  File /bin/sh should be owned by "root"
-
-  File /tmp
-     ✔  should be directory
-  alice should
-     ✖  eq "bob"
-
-     expected: "bob"
-          got: "alice"
-
-     (compared using ==)
-
-  should eq
-     ✖  "secret"
-
-     expected: "secret"
-          got: nil
-
-     (compared using ==)
-
-
-Test Summary: 3 successful, 2 failures, 1 skipped
-```
-
-To pass in attributes, just call:
-
-```
-$ inspec exec examples/inheritance --attrs examples/profile-attribute.yml
-```

data/examples/inheritance/controls/example.rb

@@ -1,14 +0,0 @@
-# encoding: utf-8
-# copyright: 2016, Chef Software, Inc.
-
-# manipulate controls of `profile`
-include_controls 'profile' do
-  skip_control 'tmp-1.0'
-
-  control 'gordon-1.0' do
-    impact 0.0
-  end
-end
-
-# load all controls of `profile-attribute`
-include_controls 'profile-attribute'

data/examples/inheritance/inspec.yml

@@ -1,16 +0,0 @@
-name: inheritance
-title: InSpec example inheritance
-maintainer: Chef Software, Inc.
-copyright: Chef Software, Inc.
-copyright_email: support@chef.io
-license: Apache-2.0
-summary: Demonstrates the use of InSpec profile inheritance
-version: 1.0.0
-supports:
-  - platform-family: unix
-  - platform-family: windows
-depends:
-  - name: profile
-    path: ../profile
-  - name: profile-attribute
-    path: ../profile-attribute

data/examples/kitchen-ansible/.kitchen.yml

@@ -1,25 +0,0 @@
----
-driver:
-  name: vagrant
-
-provisioner:
-  hosts: webservers
-  name: ansible_playbook
-  # Use el7 epel repo instead of the default el6
-  ansible_yum_repo: "https://download.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm"
-  require_chef_for_busser: false
-  require_ruby_for_busser: false
-  ansible_verbosity: 2
-  ansible_verbose: true
-  # starting playbook is at: test/integration/default/default.yml
-
-verifier:
-  name: inspec
-
-platforms:
-  - name: centos-7.1
-  - name: ubuntu-12.04
-  - name: ubuntu-14.04
-
-suites:
-  - name: default

data/examples/kitchen-ansible/Gemfile

@@ -1,19 +0,0 @@
-# encoding: utf-8
-source 'https://rubygems.org'
-
-gem 'inspec', path: '../../.'
-
-group :test do
-  gem 'bundler', '~> 1.5'
-  gem 'minitest', '~> 5.5'
-  gem 'rake', '~> 10'
-  gem 'simplecov', '~> 0.10'
-end
-
-group :integration do
-  gem 'test-kitchen', '~> 1.4'
-  gem 'kitchen-ansible'
-  gem 'kitchen-vagrant'
-  gem 'kitchen-inspec'
-  gem 'concurrent-ruby', '~> 1.0'
-end

data/examples/kitchen-ansible/README.md

@@ -1,53 +0,0 @@
-# Test-Kitchen - InSpec with Ansible Example
-
-This example demonstrates a complete roundtrip via [Test-Kitchen](http://kitchen.ci/).
-
-```bash
-# install all dependencies
-$ bundle install
-# show all available tests
-$ bundle exec kitchen list
-Instance             Driver   Provisioner      Verifier  Transport  Last Action
-default-centos-71    Vagrant  AnsiblePlaybook  Inspec    Ssh        <Not Created>
-default-ubuntu-1204  Vagrant  AnsiblePlaybook  Inspec    Ssh        <Not Created>
-default-ubuntu-1404  Vagrant  AnsiblePlaybook  Inspec    Ssh        <Not Created>
-
-# Now we are ready to run a complete test
-$ bundle exec kitchen test default-ubuntu-1404
------> Starting Kitchen (v1.4.2)
------> Cleaning up any prior instances of <default-ubuntu-1404>
------> Destroying <default-ubuntu-1404>...
-       Finished destroying <default-ubuntu-1404> (0m0.00s).
------> Testing <default-ubuntu-1404>
------> Creating <default-ubuntu-1404>...
-       Bringing machine 'default' up with 'virtualbox' provider...
-       ==> default: Importing base box 'opscode-ubuntu-14.04'...
-
-...
-
-       Vagrant instance <default-ubuntu-1404> created.
-       Finished creating <default-ubuntu-1404> (0m37.51s).
------> Converging <default-ubuntu-1404>...
-       Preparing files for transfer
-       Preparing playbook
-
-...
-
-       Finished converging <default-ubuntu-1404> (1m14.53s).
------> Setting up <default-ubuntu-1404>...
-       Finished setting up <default-ubuntu-1404> (0m0.00s).
------> Verifying <default-ubuntu-1404>...
-.....
-
-Finished in 0.08796 seconds (files took 1 minute 52.3 seconds to load)
-5 examples, 0 failures
-
-       Finished verifying <default-ubuntu-1404> (0m0.27s).
------> Destroying <default-ubuntu-1404>...
-       ==> default: Forcing shutdown of VM...
-       ==> default: Destroying VM and associated drives...
-       Vagrant instance <default-ubuntu-1404> destroyed.
-       Finished destroying <default-ubuntu-1404> (0m4.41s).
-       Finished testing <default-ubuntu-1404> (1m56.73s).
------> Kitchen is finished. (1m57.06s)
-```