Giter VIP home page Giter VIP logo

inspec's Introduction

Chef InSpec: Inspect Your Infrastructure

  • Project State: Active
  • Issues Response SLA: 14 business days
  • Pull Request Response SLA: 14 business days

For more information on project states and SLAs, see this documentation.

Slack Build status Coverage Status

Chef 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

Chef 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 via 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 Chef InSpec 1.7.1
inspec exec test.rb -t ssh://user@hostname

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

# run test on remote windows host via WinRM as a domain user
inspec exec test.rb -t winrm://windowshost --user 'UserName@domain' --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: Chef 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

Chef InSpec requires Ruby ( >= 3.0.3 ).

All currently supported versions of Chef InSpec (4.0 and later) require accepting the EULA to use. Please visit the license acceptance page on the Chef docs site for more information.

Install as package

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

# RedHat, Ubuntu, and macOS
curl https://chefdownload-commercial.chef.io/install.sh?license_id=<LICENSE_ID> | sudo bash -s -- -P inspec

# Windows
. { iwr -useb https://chefdownload-commercial.chef.io/install.ps1?license_id=<LICENSE_ID> } | iex; install -project inspec

Replace <LICENSE_ID> with your license ID.

For more information about the install scripts, see the Chef Install Script documentation.

Install it via rubygems.org

Installing Chef InSpec from source may require installing ruby build tools to manage gem dependencies. (A compiler-free variant is available with reduced functionality; use inspec-core-bin and inspec-core.)

To install build tools, use your package manager.

For CentOS/RedHat/Fedora:

yum -y install ruby ruby-devel make gcc gcc-c++

For Ubuntu:

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

To install the inspec executable, which requires accepting the Chef License, run:

gem install inspec-bin

You may also use inspec as a library, with no executable. This does not require accepting the license. To install the library as a gem, run:

gem install inspec

Usage via Docker

Download the image and define a function for convenience:

For Linux:

docker pull chef/inspec
function inspec { docker run -it --rm -v $(pwd):/share chef/inspec "$@"; }

For Windows (PowerShell):

docker pull chef/inspec
function inspec { docker run -it --rm -v "$(pwd):/share" chef/inspec $args; }

If you call inspec from your shell, it automatically mounts the current directory into the Docker container. Therefore you can easily use local tests and key files. Note: Only files in the current directory and sub-directories are available within the container.

$ ls -1
vagrant
test.rb

$ inspec exec test.rb -t ssh://[email protected]:11022 -i vagrant
..

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

To scan the docker containers running on the host using the containerized InSpec, we need to bind-mount the Unix socket /var/run/docker.sock from the host machine to the InSpec Container.

docker pull chef/inspec
function inspec { docker run -it --rm -v $(pwd):/share -v /var/run/docker.sock:/var/run/docker.sock chef/inspec "$@"; }

/var/run/docker.sock is the Unix socket the Docker daemon listens on by default.

Install it from source

Note that installing from OS packages from the download page is the preferred method.

That requires bundler:

bundle install
bundle exec 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 Chef Habitat

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

Download the hab binary from the Chef Habitat site.

hab pkg install chef/inspec --binlink

inspec

Run Chef 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 automate SUBCOMMAND ...                            # Chef Automate commands
  inspec compliance SUBCOMMAND ...                          # Chef Automate commands (backwards compatible alias)
  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
  • Test your kitchen.yml file to verify that only Vagrant is configured as the driver. The %w() formatting will pass rubocop linting 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 test on podman container
inspec exec test.rb -t podman://container_id --podman-url "unix:///run/user/1000/podman/podman.sock"

# 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 ...]

# run a profile targeting AWS using env vars
inspec exec test.rb -t aws://

# or store your AWS credentials in your ~/.aws/credentials profiles file
inspec exec test.rb -t aws://us-east-2/my-profile

# run a profile targeting Azure using env vars
inspec exec test.rb -t azure://

# or store your Azure credentials in your ~/.azure/credentials profiles file
inspec exec test.rb -t azure://subscription_id

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 6, 7, 8 i386, x86_64
Debian 9, 10 i386, x86_64
FreeBSD 9, 10, 11 i386, amd64
macOS 11.0 x86_64
Oracle Enterprise Linux 6, 7, 8 i386, x86_64
Red Hat Enterprise Linux 7, 8, 9 i386, x86_64
Solaris 10, 11 sparc, x86
Windows* 8, 8.1, 10, 2012, 2012R2, 2016, 2019 x86, x86_64
Ubuntu Linux x86, x86_64
SUSE Linux Enterprise Server 12, 15 x86_64
Scientific Linux 6, 7 i386, x86_64
Fedora x86_64
OpenSUSE 15 x86_64
OmniOS x86_64
Gentoo Linux x86_64
Arch Linux x86_64
HP-UX 11.31 ia64
Alpine Linux x86_64

*For Windows, PowerShell 5.0 or above is required.

In addition, runtime support is provided for:

Platform Versions Arch
macOS 11+ x86_64, arm64
Debian 9, 10 x86_64, aarch64
RHEL 7, 8, 9 x86_64, aarch64
Fedora 29+ x86_64, aarch64
Ubuntu 16.04+ x86_64, aarch64
Windows 8+ x86_64
Windows 2012+ x86_64

Documentation

Documentation

Learn Chef:

Relationship to other tools (RSpec, Serverspec):

Share your Profiles

You may share your Chef 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

Chef InSpec was originally created by Christoph Hartmann (@chris-rock) and Dominik Richter (@arlimus).

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

The AWS resources were inspired by inspec-aws from arothian.

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 Chef InSpec community and maintainers are very active and helpful. This project benefits greatly from this activity.

If you'd like to chat with the community and maintainers directly join us in the #inspec channel on the Chef Community Slack.

As a reminder, all participants are expected to follow the Code of Conduct.

Slack

Testing Chef InSpec

We offer 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 Chef 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:

KITCHEN_YAML=kitchen.dokken.yml bundle exec kitchen list

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

KITCHEN_YAML=kitchen.dokken.yml bundle exec kitchen test <INSTANCE_NAME>

You may test all instances in parallel with:

KITCHEN_YAML=kitchen.dokken.yml bundle exec kitchen test -c 3

License

Author: Dominik Richter ([email protected])
Author: Christoph Hartmann ([email protected])
Copyright: Copyright (c) 2015 Vulcano Security GmbH.
Copyright: Copyright (c) 2017-2020 Chef Software Inc.
Copyright: Copyright (c) 2020-2023 Progress Software Corp.
License: Apache License, Version 2.0
License: Chef End User License Agreement

Packaged distributions of Progress® Chef® products obtained from any authorised Progress Chef distribution source are made available pursuant to the Progress Chef EULA at https://www.chef.io/end-user-license-agreement, unless there is an executed agreement in effect between you and Progress that covers the Progress Chef products ("Master Agreement"), in which case the Master Agreement shall govern.

Source code obtained from the Chef GitHub repository is made available under Apache-2.0, a copy of which is included below.

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.

inspec's People

Contributors

aaronlippold avatar adamleff avatar ahasunos avatar alexpop avatar arlimus avatar btm avatar chef-ci avatar chef-delivery avatar chris-redekop avatar chris-rock avatar clintoncwolfe avatar dependabot[bot] avatar dkumaras avatar ianmadd avatar jeremymv2 avatar jerryaldrichiii avatar jquick avatar kekaichinose avatar magwalk avatar mbaitelman avatar miah avatar nik08 avatar russellseymour avatar sathish-progress avatar srenatus avatar stevendanna avatar tas50 avatar tduffield avatar vasu1105 avatar zenspider avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

inspec's Issues

Custom resource not available, undefined local variable or method `gordon_config`

I've followed the setup instructions... gem install, simple file with example GordonConfig. Through debugging I see that the resource is listed in the registry. However, I am seeing:

app_server_spec.rb:19:in `load': undefined local variable or method `gordon_config' for #<#<Class:0x007fb204862a78>:0x007fb204862528> (NameError)
    from /Users/aiwilliams/.rbenv/versions/2.1.6/lib/ruby/gems/2.1.0/gems/inspec-0.9.2/lib/inspec/profile_context.rb:31:in `instance_eval'
    from /Users/aiwilliams/.rbenv/versions/2.1.6/lib/ruby/gems/2.1.0/gems/inspec-0.9.2/lib/inspec/profile_context.rb:31:in `load'
    from /Users/aiwilliams/.rbenv/versions/2.1.6/lib/ruby/gems/2.1.0/gems/inspec-0.9.2/lib/inspec/runner.rb:76:in `add_content'
    from /Users/aiwilliams/.rbenv/versions/2.1.6/lib/ruby/gems/2.1.0/gems/inspec-0.9.2/lib/inspec/runner.rb:57:in `block in add_tests'
    from /Users/aiwilliams/.rbenv/versions/2.1.6/lib/ruby/gems/2.1.0/gems/inspec-0.9.2/lib/inspec/runner.rb:56:in `each'
    from /Users/aiwilliams/.rbenv/versions/2.1.6/lib/ruby/gems/2.1.0/gems/inspec-0.9.2/lib/inspec/runner.rb:56:in `add_tests'
    from /Users/aiwilliams/.rbenv/versions/2.1.6/lib/ruby/gems/2.1.0/gems/inspec-0.9.2/bin/inspec:77:in `exec'
    from /Users/aiwilliams/.rbenv/versions/2.1.6/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
    from /Users/aiwilliams/.rbenv/versions/2.1.6/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
    from /Users/aiwilliams/.rbenv/versions/2.1.6/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
    from /Users/aiwilliams/.rbenv/versions/2.1.6/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
    from /Users/aiwilliams/.rbenv/versions/2.1.6/lib/ruby/gems/2.1.0/gems/inspec-0.9.2/bin/inspec:109:in `<top (required)>'
    from /Users/aiwilliams/.rbenv/versions/2.1.6/bin/inspec:23:in `load'
    from /Users/aiwilliams/.rbenv/versions/2.1.6/bin/inspec:23:in `<main>'

Some inconsistencies with naming across the resources

Configuration File Resources

Some of the resources have a name that includes _config (spelled out), whereas others are shortened to just _conf.

Ones that have _config:

inetd_config << suggest inetd_conf
parse_config
parse_config_file
ssh_config
sshd_config

_conf:
apache_conf
audit_daemon_conf << suggest auditd_conf
limits_conf
mysql_conf
ntp_conf
postgres_conf

Only two of them are truly inconsistent, with inetd_config and audit_daemon_conf not having a name directly similar to the actual filename, like ntp_conf and the other _conf resources. Naming suggestions listed above.

parse_config options

  • suggest renaming assignment_re => assign_regex << no more guessing as to what _re might mean
  • suggest renaming key_vals => key_values (to be consistent with multiple_values and to preserve the highest level of human readability)

Miscellaneous (these are not as important)

  • The name of the login_def (file name) resource is login_defs (resource name) << can both be the same (plural)? This suggestion changes the resource filename to login_defs.rb
  • The name of the processes resource << can it be shortened to just process? It also seems that one can test just a single "process"
  • There is an /etc/group => etc_group resource, there is an /etc/passwd => passwd resource ... could the passwd resource be named etc_passwd? (Note that I see why it's etc_group, specifically, so as to not conflict with the group resource.)

`inspec check` on examples generates errors

The command line description of inspec check says that it will verify the test structure. Used on the example in this repo, however, returns warnings and errors:

[test-kitchen]$ ll                                                                                                                                                            
total 48
drwxr-xr-x  11 tball  staff   374B Nov  3 19:51 .
drwxr-xr-x   3 tball  staff   102B Nov  3 10:49 ..
drwxr-xr-x   4 tball  staff   136B Nov  3 13:40 .kitchen
-rw-r--r--   1 tball  staff   246B Nov  3 10:49 .kitchen.yml
-rw-r--r--   1 tball  staff    47B Nov  3 10:49 Berksfile
-rw-------   1 tball  staff   145B Nov  3 13:39 Berksfile.lock
-rw-r--r--   1 tball  staff   498B Nov  3 19:51 Gemfile
-rw-r--r--   1 tball  staff   896B Nov  3 10:49 README.md
-rw-r--r--   1 tball  staff   191B Nov  3 10:49 metadata.rb
drwxr-xr-x   4 tball  staff   136B Nov  3 10:49 recipes
drwxr-xr-x   3 tball  staff   102B Nov  3 10:49 test
[test-kitchen]$ chef exec inspec check .
W, [2015-11-04T14:38:32.092497 #27616]  WARN -- : metadata.rb doesn't support: depends ["apt"]
W, [2015-11-04T14:38:32.092578 #27616]  WARN -- : metadata.rb doesn't support: depends ["yum"]
I, [2015-11-04T14:38:32.153793 #27616]  INFO -- : Checking profile in .
E, [2015-11-04T14:38:32.154004 #27616] ERROR -- : Profile name must be defined as: OWNER/ID
D, [2015-11-04T14:38:32.154080 #27616] DEBUG -- : Found 7 rules.
D, [2015-11-04T14:38:32.154114 #27616] DEBUG -- : Verify all rules in  ./test/integration/default/web_spec.rb
W, [2015-11-04T14:38:32.154173 #27616]  WARN -- : Rule web_spec.rb:6 has no title
W, [2015-11-04T14:38:32.154226 #27616]  WARN -- : Rule web_spec.rb:6 has no description
W, [2015-11-04T14:38:32.154279 #27616]  WARN -- : Rule web_spec.rb:26 has no title
W, [2015-11-04T14:38:32.154320 #27616]  WARN -- : Rule web_spec.rb:26 has no description

We should clean up the built in examples so they pass inspec check

Proper Changelog

Can the maintainers please update the CHANGELOG.md to a good format? It also appears that the CHANGELOG.md is currently out of date -- the most current version on Rubygems is 0.9.1, and the changelog only covers to 0.8.0.

Here is a good way to do a changelog:

Release 0.1.0 YYYY/MM/DD

Initial release of example_inspec

  • We added a feature, here's a short description.
  • We added another feature.
  • Also we fixed this bug, rejoice!

[#25] A github style reference to github issue 25.
[#431] Another github style reference.

os_env not working

I used os_env but i don't get a result from it. I tested it in inspec shell

command('echo $PATH').stdout => "/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl\n"

vs

os_env('PATH').content => nil

Support writing full tests in inspec shell

At the moment it is not possible to start an inspec shell and paste either a control or a describe block and have it execute and report results.

I.e:

inspec shell

And then enter:

describe file('/not/here') do
   it { should_not exist }
end

which will only result in:

=> [["describe", [File /not/here], #<Proc:0x000000013f3850@(pry):1>]]

The desired output should be:

  1. A print of the execution using the default cli formatter, without the additonal profile context and version. i.e.:

        ssh-1: Allow only SSH Protocol 2
  2. The test should return a result object, which has a result value embedded.

file resource mode matcher does not display file permissions correctly on failure

When a file does not match the intended mode value, the failure return does not list what the mode is in the typical fashion, i.e., 0644, 0777, etc. Instead, as in the following example, it returns that it should equal 416 but instead equals 420. I would expect it to return the file permissions.

root@997d17a0fd01:~# cat spec.rb
describe file('/root/file') do
    its('mode') { should eq 0640 }
end
root@997d17a0fd01:~# ls -l file
-rw-r--r-- 1 root root 0 Nov 10 18:17 file
root@997d17a0fd01:~# inspec exec spec.rb
F

Failures:

  1) File /root/file mode should eq 416
     Failure/Error: its('mode') { should eq 0640 }

       expected: 416
            got: 420

       (compared using ==)
     # spec.rb:2:in `block (2 levels) in load'
     # /var/lib/gems/1.9.1/gems/inspec-0.9.2/lib/inspec/runner.rb:89:in `run_with'
     # /var/lib/gems/1.9.1/gems/inspec-0.9.2/lib/inspec/runner.rb:85:in `run'
     # /var/lib/gems/1.9.1/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
     # /var/lib/gems/1.9.1/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
     # /var/lib/gems/1.9.1/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
     # /var/lib/gems/1.9.1/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'

Finished in 0.04819 seconds (files took 0.21259 seconds to load)
1 example, 1 failure

Failed examples:

rspec  # File /root/file mode should eq 416

docker resources

    describe docker.container('busybox') do
      it { should exist }
      it { should be_running }
    end

    describe docker.image('busybox:latest') do
      it { should exist }
    end

directory: add globbing

the resource should cover cases like:

Dir.glob('c:/inetpub/wwwroot/**/*.htm') { |web_file|
  ..
}

registry_key needs to be case insensitive

Repro steps:

  1. Take a Windows 2012r2 instance and run the following Powershell command:
PS C:\> Get-ItemProperty -Path HKLM:\System\CurrentControlSet\Control\Lsa\MSV1_0 -name NTLMMinServerSec

NtlmMinServerSec : 536870912
  1. Use this chef-client resource to set NTLMMinServerSec to the desired value:
registry_key 'HKLM\System\CurrentControlSet\Control\Lsa\MSV1_0' do
  values [{ name: 'NTLMMinServerSec', type: :dword, data: 537_395_200 }]
  recursive true
  action :create
end
  1. Run the following Powershell command to retrieve the value of the registry key:
PS C:\> Get-ItemProperty -Path HKLM:\System\CurrentControlSet\Control\Lsa\MSV1_0 -name NTLMMinServerSec

NtlmMinServerSec : 537395200

^ This shows that the chef-client registry_key resource found the entry and set the desired value. Observe the case insensitive nature of the NTLM in the Powershell and chef-client context.

  1. Run an inspec test using this rule, currently used in compliance-profiles/base/windows/test/base_spec.rb:
rule 'windows-base-203' do
  impact 1.0
  title 'Enable Strong Encryption for Windows Network Sessions on Servers'
  describe registry_key('HKLM\System\CurrentControlSet\Control\Lsa\MSV1_0') do
    it { should exist }
    its('NTLMMinServerSec') { should eq 537395200 }
  end
end
  1. Run an inspec test using this rule:
rule 'windows-base-203' do
  impact 1.0
  title 'Enable Strong Encryption for Windows Network Sessions on Servers'
  describe registry_key('HKLM\System\CurrentControlSet\Control\Lsa\MSV1_0') do
    it { should exist }
    its('NtlmMinServerSec') { should eq 537395200 }
  end
end

Expected results:

  • Test 4 succeeds
  • Test 5 succeeds

Actual results:

  • Test 4 fails with this output:
    3) Registry Key HKLM\System\CurrentControlSet\Control\Lsa\MSV10 NTLMMinServerSec
       Failure/Error: its('NTLMMinServerSec') { should eq 537395200 }
       NoMethodError:
         undefined method `[]' for nil:NilClass
       # /Users/apop/.chefdk/gem/ruby/2.1.0/gems/inspec-0.9.3/lib/resources/registry_key.rb:56:in `method_missing'
       # demo/windows/test/random.rb:48:in `block (3 levels) in load'
  • Test 5 succeeds

Test 4 fails because the registry_key inspec resource is case sensitive.

document output and/or expected results

All of the inspec exec examples provide no hints as to what the expected outcome should be. For those who don't come from a Ruby universe, this is particularly confusing. Is it just a pass/fail as a return value? Is it JSON? Is it unformatted text? Is it rspec? Is it TAP?

It seems extremely realistic that someone would want to hook this up to, say, Jenkins. But with the lack of documentation on the consumer output, many will just take a pass and move on to something else.

Better wording for check

Documentation for inspec command check:

Use inspec check to run all tests at the specified path.

Documentation for inspec command exec:

Use inspec exec to run all tests at the specified path.

What is the difference?

Reported by @alexmanly

Cannot run against remote WinRM SSL systems

When I attempt to run a simple inspec file (just contains the port 80 should not not be open example from the readme), I get the following error:

troyready@myworkstation:~/myscripts$ ~/.chefdk/gem/ruby/2.1.0/bin/inspec exec inspec_recent_patching.rb -b winrm --user Administrator --host mywinhost.myorg.com --password "mypa33w#rd" --ssl --self-signed
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/winrm-1.3.4/lib/winrm/http/response_handler.rb:57:in `raise_if_auth_error': WinRM::WinRMAuthorizationError (WinRM::WinRMAuthorizationError)
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/winrm-1.3.4/lib/winrm/http/response_handler.rb:50:in `raise_if_error'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/winrm-1.3.4/lib/winrm/http/response_handler.rb:35:in `parse_to_xml'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/winrm-1.3.4/lib/winrm/http/transport.rb:50:in `send_request'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/winrm-1.3.4/lib/winrm/winrm_service.rb:430:in `send_message'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/winrm-1.3.4/lib/winrm/winrm_service.rb:126:in `open_shell'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/winrm-transport-1.0.2/lib/winrm/transport/command_executor.rb:78:in `open'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/r-train-0.9.1/lib/train/transports/winrm_connection.rb:158:in `block in establish_shell'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/r-train-0.9.1/lib/train/transports/winrm_connection.rb:212:in `retryable'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/r-train-0.9.1/lib/train/transports/winrm_connection.rb:156:in `establish_shell'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/r-train-0.9.1/lib/train/transports/winrm_connection.rb:238:in `session'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/r-train-0.9.1/lib/train/transports/winrm_connection.rb:66:in `run_command'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/r-train-0.9.1/lib/train/extras/os_detect_windows.rb:60:in `detect_windows'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/r-train-0.9.1/lib/train/extras/os_common.rb:105:in `detect_family_type'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/r-train-0.9.1/lib/train/extras/os_common.rb:78:in `detect_family'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/r-train-0.9.1/lib/train/extras/os_common.rb:26:in `initialize'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/r-train-0.9.1/lib/train/transports/winrm_connection.rb:254:in `initialize'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/r-train-0.9.1/lib/train/transports/winrm_connection.rb:54:in `new'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/r-train-0.9.1/lib/train/transports/winrm_connection.rb:54:in `os'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/inspec-0.9.1/lib/resources/os.rb:16:in `[]'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/inspec-0.9.1/lib/resources/port.rb:26:in `initialize'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/inspec-0.9.1/lib/inspec/plugins/resource.rb:23:in `initialize'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/inspec-0.9.1/lib/inspec/profile_context.rb:74:in `new'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/inspec-0.9.1/lib/inspec/profile_context.rb:74:in `block (3 levels) in create_inner_dsl'
    from inspec_recent_patching.rb:1:in `load'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/inspec-0.9.1/lib/inspec/profile_context.rb:31:in `instance_eval'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/inspec-0.9.1/lib/inspec/profile_context.rb:31:in `load'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/inspec-0.9.1/lib/inspec/runner.rb:76:in `add_content'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/inspec-0.9.1/lib/inspec/runner.rb:57:in `block in add_tests'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/inspec-0.9.1/lib/inspec/runner.rb:56:in `each'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/inspec-0.9.1/lib/inspec/runner.rb:56:in `add_tests'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/inspec-0.9.1/bin/inspec:77:in `exec'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/gems/inspec-0.9.1/bin/inspec:109:in `<top (required)>'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/bin/inspec:23:in `load'
    from /home/troyready/.chefdk/gem/ruby/2.1.0/bin/inspec:23:in `<main>'

I tried connecting directly with train though and I don't experience any errors:

require 'train'
train = Train.create(
  'winrm',
  host: 'mywinhost.myorg.com',
  user: 'Administrator',
  password: 'mypa33w#rd',
  ssl: true,
  self_signed: true
)
conn = train.connection
puts conn.run_command('ipconfig /all').stdout
conn.close

(^ outputs my ip info as expected)

I've tried debugging this for a bit and didn't come up with anything conclusive. Would greatly appreciate any advice/direction on troubleshooting it / improving the project.

Port resource returns arrays

process, pid and protocol for port all get compared to an array instead of string/number causing weirdness like this

Port  22 pid should eq "957"
    Failure/Error: DEFAULT_FAILURE_NOTIFIER = lambda { |failure, _opts| raise failure }

      expected: "957"
           got: [957]

Thanks for reporting Thomas Cate

OS detection on debian does not detect versions

The new OS detector does not play nice with Debian yet. detect.rb returns the following data:

{"os_name":null,"os_family":"debian","os_release":null,"os_arch":"x86_64"}

The version is missing.

script resource

Currently we have no built-in support to run long powershell scripts.

Readme: differentiate from Serverspec

Kudos for giving a nod to Serverspec.

It would be really helpful to explain why this is different from serverspec and why someone might choose to use inspec instead of serverspec.

User resource doesn't handle group names with spaces

On a Linux server that is joined to a Windows domain, users generaly are member of groups that contain spaces in their names. Eg "domain users". However, this currenly fails.

Test:

describe user('jfolmer') do
  its('groups') { should eq ['domain users', 'domain admins', 'denied rodc password replication group'] }
end

Output:

Failures:

  1) User jfolmer groups should eq ["domain users", "domain admins", "denied rodc password replication group"]
     Failure/Error: DEFAULT_FAILURE_NOTIFIER = lambda { |failure, _opts| raise failure }

       expected: ["domain users", "domain admins", "denied rodc password replication group"]
            got: ["domain"]

OS resource requires requires a Symbol not a String (wrong in docs)

Platform: Windows 10/ChefDK 0.9/InSpec 0.9 + Test Kitchen/AzureRM driver/Windows 2012 R2 Datacenter instance.

As per https://docs.chef.io/release/compliance_1-0/inspec_os.html

Input:

describe os['family'] do
  it { should eq 'windows' }
end

Outcome:

  1)  should eq "windows"
     Failure/Error: it { should eq 'windows' }

       expected: "windows"
            got: nil

       (compared using ==)

Correct usage appears to be:

describe os[:family] do
  it { should eq 'windows' }
end

Submitting a doc PR for this shortly.

service resource misbehaves on upstart hosts

Some services, like ntp, don't show up in initctl on Ubuntu 14.04 and other pre-systemd platforms. They are visible in /etc/init.d and via the service command, but are not in initctl.

Currently, inspec checks initctl for all service resources on pre-15.04 hosts, so it will fail to detect running ntp processes, even though they are present and enabled.

I'm not sure what the proper fix here is, possibly checking /etc/init.d/, service, and initctl for a service, and or-ing the results together?

specify process supervision type in service resource

The Inspec service resource determines the process supervision type based on os release version and uses a single process supervision type to check if a process is running, enabled etc.

Given many chef cookbooks use many different process supervison tools (init, upstart, runit, etc etc) It would be better if you could override the service_mgmt instance variable to specify the specific one for your service.

Is this a design decision, or could this be changed?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.