inspec 2.0.32 → 2.0.45

data/docs/inspec_and_friends.md

@@ -1,107 +1,107 @@
----
-title: InSpec and friends
----
-
-# InSpec and friends
-
-This page looks at projects that are similar to InSpec to explain how they
-relate to each other.
-
-## RSpec
-
-RSpec is an awesome framework that is widely used to test Ruby code. It
-enables test-driven development (TDD) and helps developers to write
-better code every day.
-
-InSpec is built on top of RSpec and uses it as the underlying foundation
-to execute tests. It uses the key strengths of RSpec, easily execute
-tests and a DSL to write tests, but extends the functionality for use as
-compliance audits. InSpec ships with custom audit resources that make it
-easy to write audit checks and with the ability to run those checks on
-remote servers. These audit resources provided know the differences
-between operating systems and help you abstract from the local operating
-system, similar to other resources you might use in your Chef recipes.
-
-A complete InSpec rule looks like:
-
-```ruby
-control "sshd-11" do
-  impact 1.0
-  title "Server: Set protocol version to SSHv2"
-  desc "Set the SSH protocol version to 2. Don't use legacy
-        insecure SSHv1 connections anymore."
-  tag security: "level-1"
-  tag "openssh-server"
-  ref "Server Security Guide v.1.0", url: "http://..."
-
-  describe sshd_config do
-    its('Protocol') { should eq('2') }
-  end
-end
-```
-
-## Serverspec
-
-Serverspec is the first extension of RSpec that enabled
-users to run RSpec tests on servers to verify deployed artifacts. It was
-created in March 2013 by Gosuke Miyashita and has been widely adopted.
-It is also one of the core test frameworks within test-kitchen and has
-been widely used within the Chef ecosystem. InSpec takes lessons learned
-implementing and using Serverspec and builds on them to make auditing
-and compliance easier.
-
-Lessons learned from Serverspec include:
-
-* IT, compliance, and security professional require metadata beyond what Serverspec offers, such as criticality, to fully describe controls.
-* Setting up and running the same tests across multiple machines must be easy.
-* It must be easy to locate, debug, and extend operating system-dependent code.
-* It must be easy to extend the language and create custom resources.
-* It must run multiple tests simultaneously.
-* Support for Windows is a first-class requirement.
-* A command line interface (CLI) is required for faster iteration of test code.
-
-You can also watch this [podcast](http://foodfightshow.org/2016/02/inspec.html) to find out more on the relationship of InSpec and Serverspec.
-
-### How is InSpec different from Serverspec
-
-One of the key differences is that InSpec targets more user groups. It
-is optimized for DevOps, Security, and Compliance professionals.
-Additional metadata, such as impact, title, and description, make it
-easier to fully describe the controls which makes it easier to share the
-controls with other departments. This enables Security departments to
-prioritize rules. DevOps teams use this information to focus on the most
-critical issues to remediate.
-
-```ruby
-control "sshd-11" do
-  impact 1.0
-  title "Server: Set protocol version to SSHv2"
-  desc "Set the SSH protocol version to 2. Don't use legacy
-        insecure SSHv1 connections anymore."
-  tag security: "level-1"
-  tag "openssh-server"
-  ref "Server Security Guide v.1.0" url: "http://..."
-
-  describe sshd_config do
-    its('Protocol') { should cmp 2 }
-  end
-end
-```
-
-**Why not fork Serverspec?**
-
-InSpec started as an extension of Serverspec. As the extension grew, it
-became clear that a new library was required. Creating and maintaining a
-fork was not practical so a new project was born.
-
-**Will InSpec only work on machines managed by Chef?**
-
-No, InSpec can be used on any machine. It doesn’t matter if that machine
-was configured by Chef or configured lovingly by the hands of your local
-System Administrator.
-
-**Is InSpec a replacement of Serverspec?**
-
-InSpec is intended to be a drop-in replacement of Serverspec. Popular
-Serverspec resources have been ported to InSpec. It changed some
-behaviour as documented in our migration guide.
+---
+title: InSpec and friends
+---
+
+# InSpec and friends
+
+This page looks at projects that are similar to InSpec to explain how they
+relate to each other.
+
+## RSpec
+
+RSpec is an awesome framework that is widely used to test Ruby code. It
+enables test-driven development (TDD) and helps developers to write
+better code every day.
+
+InSpec is built on top of RSpec and uses it as the underlying foundation
+to execute tests. It uses the key strengths of RSpec, easily execute
+tests and a DSL to write tests, but extends the functionality for use as
+compliance audits. InSpec ships with custom audit resources that make it
+easy to write audit checks and with the ability to run those checks on
+remote servers. These audit resources provided know the differences
+between operating systems and help you abstract from the local operating
+system, similar to other resources you might use in your Chef recipes.
+
+A complete InSpec rule looks like:
+
+```ruby
+control "sshd-11" do
+  impact 1.0
+  title "Server: Set protocol version to SSHv2"
+  desc "Set the SSH protocol version to 2. Don't use legacy
+        insecure SSHv1 connections anymore."
+  tag security: "level-1"
+  tag "openssh-server"
+  ref "Server Security Guide v.1.0", url: "http://..."
+
+  describe sshd_config do
+    its('Protocol') { should eq('2') }
+  end
+end
+```
+
+## Serverspec
+
+Serverspec is the first extension of RSpec that enabled
+users to run RSpec tests on servers to verify deployed artifacts. It was
+created in March 2013 by Gosuke Miyashita and has been widely adopted.
+It is also one of the core test frameworks within test-kitchen and has
+been widely used within the Chef ecosystem. InSpec takes lessons learned
+implementing and using Serverspec and builds on them to make auditing
+and compliance easier.
+
+Lessons learned from Serverspec include:
+
+* IT, compliance, and security professional require metadata beyond what Serverspec offers, such as criticality, to fully describe controls.
+* Setting up and running the same tests across multiple machines must be easy.
+* It must be easy to locate, debug, and extend operating system-dependent code.
+* It must be easy to extend the language and create custom resources.
+* It must run multiple tests simultaneously.
+* Support for Windows is a first-class requirement.
+* A command line interface (CLI) is required for faster iteration of test code.
+
+You can also watch this [podcast](http://foodfightshow.org/2016/02/inspec.html) to find out more on the relationship of InSpec and Serverspec.
+
+### How is InSpec different from Serverspec
+
+One of the key differences is that InSpec targets more user groups. It
+is optimized for DevOps, Security, and Compliance professionals.
+Additional metadata, such as impact, title, and description, make it
+easier to fully describe the controls which makes it easier to share the
+controls with other departments. This enables Security departments to
+prioritize rules. DevOps teams use this information to focus on the most
+critical issues to remediate.
+
+```ruby
+control "sshd-11" do
+  impact 1.0
+  title "Server: Set protocol version to SSHv2"
+  desc "Set the SSH protocol version to 2. Don't use legacy
+        insecure SSHv1 connections anymore."
+  tag security: "level-1"
+  tag "openssh-server"
+  ref "Server Security Guide v.1.0" url: "http://..."
+
+  describe sshd_config do
+    its('Protocol') { should cmp 2 }
+  end
+end
+```
+
+**Why not fork Serverspec?**
+
+InSpec started as an extension of Serverspec. As the extension grew, it
+became clear that a new library was required. Creating and maintaining a
+fork was not practical so a new project was born.
+
+**Will InSpec only work on machines managed by Chef?**
+
+No, InSpec can be used on any machine. It doesn’t matter if that machine
+was configured by Chef or configured lovingly by the hands of your local
+System Administrator.
+
+**Is InSpec a replacement of Serverspec?**
+
+InSpec is intended to be a drop-in replacement of Serverspec. Popular
+Serverspec resources have been ported to InSpec. It changed some
+behaviour as documented in our migration guide.

data/docs/matchers.md

@@ -1,168 +1,169 @@
----
-title: InSpec Universal Matchers Reference
----
-
-# InSpec Universal Matchers Reference
-
-InSpec uses matchers to help compare resource values to expectations. Matchers may be dedicated to a specific resource (such as the `aws_iam_root_user` resource's [`have_mfa_enabled`](https://www.inspec.io/docs/reference/resources/aws_iam_root_user/#have_mfa_enabled) matcher). If a matcher may be used on any resource type, it is _universal_.
-
-You may also use any matcher provided by [RSpec::Expectations](https://relishapp.com/rspec/rspec-expectations/docs), but those matchers are outside of InSpec's [scope of support](https://www.inspec.io/docs/reference/inspec_and_friends/#rspec).
-
-The following InSpec-supported universal matchers are available:
-
-* [`be`](#be) - make numeric comparisons
-* [`be_in`](#be_in) - look for the property value in a list
-* [`cmp`](#cmp) - general-use equality (try this first)
-* [`eq`](#eq) - type-specific equality
-* [`include`](#include) - look for an expected value in a list-valued property
-* [`match`](#match) - look for patterns in text using regular expressions
-
-<br>
-
-## be
-
-This matcher can be followed by many different comparison operators.
-Always make sure to use numbers, not strings, for these comparisons.
-
-```ruby
-describe file('/proc/cpuinfo') do
-  its('size') { should be >= 10 }
-  its('size') { should be < 1000 }
-end
-```
-
-<br>
-
-## cmp
-
-Unlike `eq`, `cmp` is a matcher for less-restrictive comparisons. It will
-try to fit the actual value to the type you are comparing it to. This is
-meant to relieve the user from having to write type-casts and
-resolutions.
-
-```ruby
-describe sshd_config do
-  its('Protocol') { should cmp 2 }
-end
-
-describe passwd.uid(0) do
-  its('users') { should cmp 'root' }
-end
-```
-
-`cmp` behaves in the following way:
-
-* Compare strings to numbers
-
-    ```ruby
-    describe sshd_config do
-      its('Protocol') { should eq '2' }
-
-      its('Protocol') { should cmp '2' }
-      its('Protocol') { should cmp 2 }
-    end
-    ```
-
-* String comparisons are not case-sensitive
-
-    ```ruby
-    describe auditd_conf do
-      its('log_format') { should cmp 'raw' }
-      its('log_format') { should cmp 'RAW' }
-    end
-    ```
-* Recognize versions embedded in strings
-
-    ```ruby
-    describe package(curl) do
-      its('version') { should cmp > '7.35.0-1ubuntu2.10' }
-    end
-    ```
-
-* Compare arrays with only one entry to a value
-
-    ```ruby
-    describe passwd.uids(0) do
-      its('users') { should cmp 'root' }
-      its('users') { should cmp ['root'] }
-    end
-    ```
-
-* Single-value arrays of strings may also be compared to a regex
-
-    ```ruby
-    describe auditd_conf do
-      its('log_format') { should cmp /raw/i }
-    end
-    ```
-
-* Improved printing of octal comparisons
-
-    ```ruby
-    describe file('/proc/cpuinfo') do
-      its('mode') { should cmp '0345' }
-    end
-
-    expected: 0345
-    got: 0444
-    ```
-<br>
-
-## eq
-
-Test for exact equality of two values.
-
-```ruby
-describe sshd_config do
-  its('RSAAuthentication') { should_not eq 'no' }
-  its('Protocol') { should eq '2' }
-end
-```
-
-`eq` fails if types don't match. Please keep this in mind, when comparing
-configuration entries that are numbers:
-
-```ruby
-its('Port') { should eq '22' } # ok
-
-its('Port') { should eq 22 }
-# fails: '2' != 2 (string vs int)
-```
-
-For less restrictive comparisons, please use `cmp`.
-
-<br>
-
-## include
-
-Verifies if a value is included in a list.
-
-```ruby
-describe passwd do
-  its('users') { should include 'my_user' }
-end
-```
-
-<br>
-
-## be_in
-
-Verifies that an item is included in a list.
-
-```ruby
-describe resource do
-  its('item') { should be_in LIST }
-end
-```
-
-<br>
-
-## match
-
-Check if a string matches a regular expression.
-
-```ruby
-describe sshd_config do
-  its('Ciphers') { should_not match /cbc/ }
-end
-```
+---
+title: InSpec Universal Matchers Reference
+---
+
+# InSpec Universal Matchers Reference
+
+InSpec uses matchers to help compare resource values to expectations.
+The following matchers are available:
+
+You may also use any matcher provided by [RSpec::Expectations](https://relishapp.com/rspec/rspec-expectations/docs), but those matchers are outside of InSpec's [scope of support](https://www.inspec.io/docs/reference/inspec_and_friends/#rspec).
+
+The following InSpec-supported universal matchers are available:
+
+* [`be`](#be) - make numeric comparisons
+* [`be_in`](#be_in) - look for the property value in a list
+* [`cmp`](#cmp) - general-use equality (try this first)
+* [`eq`](#eq) - type-specific equality
+* [`include`](#include) - look for an expected value in a list-valued property
+* [`match`](#match) - look for patterns in text using regular expressions
+
+<br>
+
+## be
+
+This matcher can be followed by many different comparison operators.
+Always make sure to use numbers, not strings, for these comparisons.
+
+```ruby
+describe file('/proc/cpuinfo') do
+  its('size') { should be >= 10 }
+  its('size') { should be < 1000 }
+end
+```
+
+<br>
+
+## cmp
+
+Unlike `eq`, `cmp` is a matcher for less-restrictive comparisons. It will
+try to fit the actual value to the type you are comparing it to. This is
+meant to relieve the user from having to write type-casts and
+resolutions.
+
+```ruby
+describe sshd_config do
+  its('Protocol') { should cmp 2 }
+end
+
+describe passwd.uid(0) do
+  its('users') { should cmp 'root' }
+end
+```
+
+`cmp` behaves in the following way:
+
+* Compare strings to numbers
+
+    ```ruby
+    describe sshd_config do
+      its('Protocol') { should eq '2' }
+
+      its('Protocol') { should cmp '2' }
+      its('Protocol') { should cmp 2 }
+    end
+    ```
+
+* String comparisons are not case-sensitive
+
+    ```ruby
+    describe auditd_conf do
+      its('log_format') { should cmp 'raw' }
+      its('log_format') { should cmp 'RAW' }
+    end
+    ```
+* Recognize versions embedded in strings
+
+    ```ruby
+    describe package(curl) do
+      its('version') { should cmp > '7.35.0-1ubuntu2.10' }
+    end
+    ```
+
+* Compare arrays with only one entry to a value
+
+    ```ruby
+    describe passwd.uids(0) do
+      its('users') { should cmp 'root' }
+      its('users') { should cmp ['root'] }
+    end
+    ```
+
+* Single-value arrays of strings may also be compared to a regex
+
+    ```ruby
+    describe auditd_conf do
+      its('log_format') { should cmp /raw/i }
+    end
+    ```
+
+* Improved printing of octal comparisons
+
+    ```ruby
+    describe file('/proc/cpuinfo') do
+      its('mode') { should cmp '0345' }
+    end
+
+    expected: 0345
+    got: 0444
+    ```
+<br>
+
+## eq
+
+Test for exact equality of two values.
+
+```ruby
+describe sshd_config do
+  its('RSAAuthentication') { should_not eq 'no' }
+  its('Protocol') { should eq '2' }
+end
+```
+
+`eq` fails if types don't match. Please keep this in mind, when comparing
+configuration entries that are numbers:
+
+```ruby
+its('Port') { should eq '22' } # ok
+
+its('Port') { should eq 22 }
+# fails: '2' != 2 (string vs int)
+```
+
+For less restrictive comparisons, please use `cmp`.
+
+<br>
+
+## include
+
+Verifies if a value is included in a list.
+
+```ruby
+describe passwd do
+  its('users') { should include 'my_user' }
+end
+```
+
+<br>
+
+## be_in
+
+Verifies that an item is included in a list.
+
+```ruby
+describe resource do
+  its('item') { should be_in LIST }
+end
+```
+
+<br>
+
+## match
+
+Check if a string matches a regular expression.
+
+```ruby
+describe sshd_config do
+  its('Ciphers') { should_not match /cbc/ }
+end
+```