No description
Find a file
Miah Johnson e33f4959e1 Allow crontab resource to read crontab at user specified paths. (#2328)
* add a emulated /etc/cron.d/crondotd file to the mocking system.

* test that we handle incoming paths correctly by rendering to_s.

* We take in both users and a path, so lets call that destination.

* To make the test pass we'll determine if we are dealing with a path or
a user and return the correct string.

* we will need the ability to determine if we are dealing with a path when either calling the crontab command or reading the file directly, so break that out into a path? method.

* remove author field.

* test contents of our crondotd file.

* we have to explicitly make @destination a String to use include?.

* when we get a path we use inspec.file to get conents, otherwise we run the crontab command.

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Add documentation for example usage with file path.

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Make path? and path_or_user private methods

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Add missing username filed to crondotd mock file

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Pass argument as a hash when testing file paths

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Expected results should include usernames when testing file paths

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Add special string `@yearly` test to crondotd mock file

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Add user to existing cron tests

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Rubocop says I need spaces after/before curly brackets

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Add user to crondotd file tests and add @yearly test

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Modify initialize to take options hash and be backwards compatible.

Change initialize default argument to create a hash by default, though
it is still possible to pass in a 'user' string argument.

@user gets set with the argument value unless its a hash, in which case
it tries to set the value of the user key, otherwise it becomes nil.

@file gets set with the value of the path key, unless it doesn't exist
in which case it becomes nil.

All hash keys are symbolized to ensure consistent access.

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Check if @path is nil to determine if we run crontab command or parse
file.

path? was removed as we're not overloading a @destination variable
anymore.

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* if @user is nil assume current user otherwise crontab for @user

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Change to complete if rather than ternary.

We have three possible cases, current user, other user, or file path.
This accounts for all of them.

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Add user to the crontab FilterTable

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Remove path? and path_or_user

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Move crontab parsing to two methods, parse_user_crontab and
parse_system_crontab

Because a command in a crontab file could have spaces we must parse user
and system crontabs differently.

When we parse user crontabs the user field will either be nil, or the requested user.

Both user and path parsers handle special strings (@yearly, @weekly,
etc). And also account for position of user in these files (or adds it
in user case)

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Update examples with user: and path:

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Add spaces after : in example docs

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Disable rubocop ClassLength check

Signed-off-by: Miah Johnson <miah@chia-pet.org>

* Moved rubocop ClassLength metric next to class instead of above the
module.

Remove unnecessary braces.

Add is_system_crontab? and is_user_crontab helper methods and use them.

Add tests to see if error conditions are raised when the resource is
invoked with missing parameters (user, or path), and on a unsupported
os.

Change initialize to group all hash functions together and raise errors
when user and path is unset. Also raise errors on unsupported operating
systems.

Change order of ternary and use is_system_crontab? rather than
@path.nil?

Signed-off-by: Miah Johnson <miah@chia-pet.org>
2017-12-07 13:50:07 +01:00
.expeditor Update expeditor version-update script (#2312) 2017-11-16 11:59:00 -05:00
.github Add a CODEOWNERS file (#2086) 2017-08-17 13:57:54 -04:00
bin Remove any "All Rights Reserved" references (#1969) 2017-06-28 04:14:19 -07:00
docs Fix incorrect case in paragraph. (#2363) 2017-12-04 11:55:33 -05:00
examples Remove rubocop from example Gemfiles (#2341) 2017-11-27 19:05:52 +01:00
habitat Habitat build works for all versions, eliminates rake (#2301) 2017-11-14 05:01:51 +01:00
lib Allow crontab resource to read crontab at user specified paths. (#2328) 2017-12-07 13:50:07 +01:00
omnibus Bump Rubocop to 0.49.1 (#2323) 2017-11-21 08:49:41 +01:00
support/ci Add rake task for flushing Fastly cache 2017-04-28 14:22:00 -04:00
tasks Bump Rubocop to 0.49.1 (#2323) 2017-11-21 08:49:41 +01:00
test Allow crontab resource to read crontab at user specified paths. (#2328) 2017-12-07 13:50:07 +01:00
www Bump Rubocop to 0.49.1 (#2323) 2017-11-21 08:49:41 +01:00
.gitignore Remove www Gemfile.lock (#2082) 2017-08-17 16:08:55 +02:00
.kitchen.chef.yml Change Atlas to VagrantCloud (#2372) 2017-12-05 12:21:06 -05:00
.kitchen.ec2.yml call ssh cookbook from prepare cookbook 2017-01-03 11:40:09 +01:00
.kitchen.vagrant.yml Add wildcard support to Utils::FindFiles (#2159) 2017-09-23 09:17:34 +02:00
.kitchen.yml update chef version for openssl cookbook 2017-05-30 23:09:21 -05:00
.rubocop.yml Bump Rubocop to 0.49.1 (#2323) 2017-11-21 08:49:41 +01:00
.travis.yml Require Ruby 2.3 and later (#2293) 2017-11-16 22:02:35 +07:00
appveyor.yml Remove bundler install during Appveyor tests (#2322) 2017-11-20 19:11:43 +01:00
Berksfile run integration tests in docker 2016-05-16 18:25:17 +02:00
CHANGELOG.md Bump version to 1.47.5 by Expeditor 2017-12-06 21:22:22 +00:00
CONTRIBUTING.md Fix issue template link in CONTRIBUTING.md (#2321) 2017-11-27 10:26:39 -05:00
Dockerfile Update CHANGELOG.md to reflect the promotion of 1.47.0 to stable 2017-12-04 22:43:03 +00:00
Gemfile Bump Rubocop to 0.49.1 (#2323) 2017-11-21 08:49:41 +01:00
inspec.gemspec Fix inspec appveyor test with the new local train transport (#2376) 2017-12-06 15:18:38 -05: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 add Alex Pop to the list of maintainers 2017-02-09 15:42:36 +01:00
MAINTAINERS.toml add Alex Pop to the list of maintainers 2017-02-09 15:42:36 +01:00
Rakefile Habitat build works for all versions, eliminates rake (#2301) 2017-11-14 05:01:51 +01:00
README.md Remove test/resources directory, update README (#2124) 2017-09-06 12:05:25 +02:00
VERSION Bump version to 1.47.5 by Expeditor 2017-12-06 21:22:22 +00:00

InSpec: Inspect Your Infrastructure

Slack 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 host using SSH agent private key authentication. Requires InSpec 1.7.1
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

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 as package

The InSpec package is available for MacOS, RedHat, Ubuntu and Windows. Download the latest package at InSpec Downloads or install InSpec via script:

# RedHat, Ubuntu, and macOS
curl https://omnitruck.chef.io/install.sh | sudo bash -s -- -P inspec

# Windows
. { iwr -useb https://omnitruck.chef.io/install.ps1 } | iex; install -project inspec

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.

Install via Habitat

Currently, this method of installation only supports Linux. See the Habitat site for more information.

Download the hab binary from the Habitat site.

hab pkg install chef/inspec
export PATH="$(hab pkg path core/ruby)/bin:$(hab pkg path chef/inspec)/bin:$PATH"

inspec

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. The %w() formatting will pass rubocop lintng and allow you to access nested mappings.
describe yaml('.kitchen.yml') do
  its(%w(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, 10, 2008, 2008R2 , 2012, 2012R2, 2016 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, PowerShell 3.0 or above 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

Tutorials/Blogs/Podcasts:

Relationship to other tools (RSpec, Serverspec):

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 and integration tests.

  • unit tests ensure the intended behaviour of the implementation
  • integration tests run against Docker-based VMs via test-kitchen and kitchen-inspec

Unit tests

bundle exec rake test

If you like to run only one test file:

bundle exec m test/unit/resources/user_test.rb

You may also run a single test within a file by line number:

bundle exec m test/unit/resources/user_test.rb -l 123

Integration tests

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

These tests require the following gems:

  • test-kitchen
  • kitchen-dokken
  • kitchen-inspec

These gems are provided via the integration group in the project's Gemfile.

In addition, these test require Docker to be available on your machine or a remote Docker machine configured via the standard Docker environment variables.

Running Integration tests

List the various test instances available:

bundle exec kitchen list`

The platforms and test suites are configured in the .kitchen.yml file. Once you know which instance you wish to test, test that instance:

bundle exec kitchen test <INSTANCE_NAME>

You may test all instances in parallel with:

bundle exec kitchen test -c

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.