inspec 0.34.1 → 1.0.0

data/docs/profiles.rst

@@ -1,169 +0,0 @@
-=====================================================
-InSpec Profiles
-=====================================================
-
-InSpec supports the creation of complex test and compliance profiles, which organize controls to support dependency management and code re-use. These profiles are standalone structures with their own distribution and execution flow.
-
-InSpec profile structure
------------------------------------------------------
-
-To create a new profile just place the files according to the following structure:
-
-.. code-block:: bash
-
-  $ tree examples/profile
-  examples/profile
-  ├── README.md
-  ├── controls
-  │   ├── example.rb
-  │   └── gordon.rb
-  ├── libraries
-  │   └── gordon_config.rb
-  └── inspec.yml
-
-
- * `inspec.yml` - includes the profile description (required)
- * `controls` - a folder which contains  all tests (required)
- * `libraries` - a folder which contains InSpec resource extensions (optional)
- * `README.md` - a best-practice readme to each explain the profile and its scope
-
-For a full example, see our `example profile`_.
-
-.. _example profile: ../examples/profile
-
-InSpec profile manifest
------------------------------------------------------
-
-Each profile has a manifest file `inspec.yml`. It looks as follows
-
-.. code-block:: yaml
-
-  name: ssh
-  title: Basic SSH
-  maintainer: Chef Software, Inc.
-  copyright: Chef Software, Inc.
-  copyright_email: support@chef.io
-  license: Proprietary, All rights reserved
-  summary: Verify that SSH Server and SSH Client are configured securely
-  version: 1.0.0
-  supports:
-    - os-family: linux
-
-
-A manifest description may contain the following values:
-
- * `name` - Identifier of the profile (required)
- * `title` - Human-readable name of the profile (optional)
- * `maintainer` - Name of the profile maintainer (optional)
- * `copyright` - Copyright holder (optional)
- * `copyright_email` - Support contact for profile (optional)
- * `license` - License of the profile (optional)
- * `summary` - One-line summary of the profile (optional)
- * `description` - Description of the profile (optional)
- * `version` - Version of the profile (optional)
- * `supports` - A list of supported targets (optional)
-
-Supported targets
------------------------------------------------------
-
-The manifest contains the `supports` flag, which specifies operating systems or even cloud systems that the profile is targeting.
-
-This list can contain simple names, names and versions, or detailed flags for the targeted system. These can freely be combined:
-
-.. code-block:: yaml
-
-  name: ssh
-  supports:
-    // Runs on any version of Debian Linux
-    - os-name: debian
-
-    // Only runs on Ubuntu 14.04
-    - os-name: ubuntu
-      release: 14.04
-
-    // Targets RedHat, CentOS, Oracle Linux ...
-    - os-family: redhat
-
-    // Or even broader
-    - platform: aws
-
-
-InSpec profile verification
------------------------------------------------------
-
-InSpec ships with a verification command that verifies the implementation of a profile:
-
-.. code-block:: bash
-
-  $ inspec check examples/profile
-
-
-InSpec profile archive
------------------------------------------------------
-
-Profiles are composed of multiple files. This hinders easy distribution of a profile. InSpec solves the problem by offering to collect all files in one archive.
-
-The InSpec profile archive format aims for flexibility and reuse of standard and common technologies:
-
- * tar and gzip (default)
- * zip
- * HTTP
-
-This should enable third-parties to easily build InSpec profile archives:
-
- * InSpec archives MUST be named with the stanard suffix
- * InSpec archives MUST be a tar.gz or zip formatted file
- * InSpec archives MUST have no duplicate entries
- * InSpec archives MAY be compressed with gzip, bzip2, or xz.
-
-InSpec is able to create profile archive for you. By default it generates a tar-file on Unix and zip on Windows or Mac.
-
-.. code-block:: bash
-
-  # will generate a example-profile.tar.gz
-  $ inspec archive examples/profile
-
-  # will generate a example-profile.zip
-  $ inspec archive examples/profile --zip
-
-
-Profile inheritance
------------------------------------------------------
-
-**Include controls of existing profile**
-
-The `include_controls` keyword allows you to import all rules from an existing profile. This can be easily extended with additional rules.
-
-.. code-block:: bash
-
-  include_controls 'cis-level-1' do
-
-    control "cis-fs-2.7" do
-      impact 1.0
-    ...
-
-  end
-
-**Inherit from a profile, but skip some rules**
-
-Sometimes, not all requirements can be fulfilled for a legacy application. To manage the derivation, you can skip certain controls with `skip_control`.
-
-.. code-block:: bash
-
-  include_controls 'cis-level-1' do
-
-    skip_control "cis-fs-2.1"
-    skip_control "cis-fs-2.2"
-
-  end
-
-**Load specific controls from another profile**
-
-.. code-block:: bash
-
-  require_controls 'cis-level-1' do
-
-    control "cis-fs-2.1"
-    control "cis-fs-2.2"
-
-  end

data/docs/readme.rst

@@ -1,105 +0,0 @@
-=====================================================
-InSpec Documentation
-=====================================================
-
-InSpec a collection of resources and matchers to test the compliance of your nodes. This documentation provides an introduction to this mechanism and shows how to write custom tests.
-
-Introduction
------------------------------------------------------
-
-At first, we add our tests to the ``test`` folder. Each test file must end with ``_spec.rb``:
-
-.. code-block:: bash
-
-    mkdir test
-    touch test/example_spec.rb
-
-We add a control to this file, to check the ``/tmp`` path in our system:
-
-.. code-block:: ruby
-
-  # encoding: utf-8
-
-  control "cis-fs-2.1" do                     # A unique ID for this control
-    impact 0.7                                # The criticality, if this control fails.
-    title "Create separate /tmp partition"    # A human-readable title
-    desc "An optional description..."
-    tag mygroup: "tag"                        # A tag can be a simple value or
-    tag "tag"                                 # can have a more complex key/value pair.
-    ref "name", url: "http://..."              # A reference to a document, uri: is optional
-    describe file('/tmp') do                  # The actual test
-      it { should be_mounted }
-    end
-  end
-
-
-Let's add another spec for checking the SSH server configuration:
-
-.. code-block:: bash
-
-    touch test/sshd_spec.rb
-
-It will contain:
-
-.. code-block:: ruby
-
-  # encoding: utf-8
-
-  # Skip all controls, if SSH doesn't exist on the system
-  only_if do
-    command('sshd').exist?
-  end
-
-  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: "openssh-server"
-    ref "Document A-12"
-
-    describe sshd_config do
-      its('Protocol') { should eq('2') }
-    end
-  end
-
-  control "sshd-7" do
-    impact 1.0
-    title "Server: Do not permit root-based login with password."
-    desc "To reduce the potential to gain full privileges
-          of a system in the course of an attack (by either misconfiguration
-          or vulnerabilities), do not allow login as root with password"
-    tag security: "openssh-server"
-    ref "Document A-12"
-
-    describe sshd_config do
-      its('PermitRootLogin') { should match(/no|without-password/) }
-    end
-  end
-
-
-Now, we are ready to run the tests locally:
-
-bundle exec bin/inspec exec demo/test/example_spec.rb
-
-.. code-block:: bash
-
-  # run tests individually
-  $ inspec exec test/example_spec.rb
-  $ inspec exec test/sshd_spec.rb
-
-  # if you want to run all test located within the directory
-  $ inspec exec ./test
-
-
-Stability Index
------------------------------------------------------
-
-Every available InSpec resource will indicate its stability. As InSpec matures, certain parts are more reliable than others. Brand new features are likely to be redesigned and marked as such.
-
-The stability indices are as follows:
-
-* ``Stability: Deprecated`` - This features will be removed in future versions, because its known for being problematic. Do not rely on it.
-* ``Stability: Experimental`` - New features may change or are removed in future versions
-* ``Stability: Stable`` - API is well established and proofed. Maintaining compatibility is a high priority
-* ``Stability: Locked`` - Only security and performance fixes are allowed