Skip to content

Latest commit

 

History

History
151 lines (106 loc) · 5.73 KB

README.md

File metadata and controls

151 lines (106 loc) · 5.73 KB
Raw

License CII Best Practices Puppet Forge Puppet Forge Downloads Build Status

Table of Contents

  1. Overview
  2. Module Description - What the module does and why it is useful
  3. Setup - The basics of getting started with simp
  4. Usage - Configuration options and additional functionality
  5. Limitations - OS compatibility, etc.
  6. Development - Guide for contributing to the module

Overview

This module is the overarching profile of SIMP managed systems. It should be the entry point for all supported SIMP configurations.

This is a SIMP module

This module is a component of the System Integrity Management Platform

If you find any issues, please submit them via JIRA.

Please read our Contribution Guide.

This module should be used within the SIMP ecosystem and will be of limited independent use

Module Description

This module provides a convenient entry point for setting up systems to meet the goals of the SIMP Project.

It is effectively a highly malleable Puppet profile that provides mechanisms for direct overall system modification and management.

Setup

What SIMP affects

The simp module is meant to be the central controller of all node configurations. The suggested usage is to place the following in your environment's site.pp:

include 'simp_options'
include 'simp'

NOTE: If using Puppet Enterprise, you can add the simp_options and simp classes to nodes via the classification interface. Do be sure to include simp_options before simp so that the simp module has appropriate access to the parameters in simp_options.

Reference

See the REFERENCE.md for a comprehensive overview of the module components.

Usage

Basic Usage

It is recommended that you start with one of the SIMP scenarios described below.

These may be set via the simp::scenario parameter via Hiera.

NOTE
  • simp::scenario always affects SIMP client systems, no matter how it was set.
  • However: SIMP servers will default to the simp scenario unless simp:scenario is set in Hiera.

You may want to tweak individual module settings and should reference the module documentation for full details.

SIMP Scenarios

The SIMP module has the following scenarios defined for getting started with different configurations easily:

  • simp

    • The default scenario. Enables all modules to support the default SIMP infrastructure configured around security best practices and compatibility with supported security policies as defined in the compliance_markup module.

  • simp_lite

    • The simp profile with some of the more aggressive security support modules disabled. These include, but are not limited to, iptables, fips, and svckill.

  • standalone

    • Applies all of the settings in the simp profile and, after a successful run, either disables puppet from running again or removes it from the system completely. Has options to ensure that there is a way to get back into the system afterwards.

  • poss

    • The Puppet Open Source Software (POSS) configuration simply attaches your node to the Puppet server and performs no additional configuration. This can be used as a starting point for building your own configuration without needing to worry about how to configure your Puppet agents.

  • remote_access

    • Adds the common remote access capabilities of SIMP to the system on top of the poss scenario.

  • none

    • Does nothing at all. All configuration is in your control.

Development

Please read our Contribution Guide.

Unit tests

Unit tests, written in rspec-puppet can be run by calling:

bundle exec rake spec

Acceptance tests

To run the system tests, you need Vagrant installed. Then, run:

bundle exec rake beaker:suites

Some environment variables may be useful:

BEAKER_debug=true
BEAKER_provision=no
BEAKER_destroy=no
BEAKER_use_fixtures_dir_for_modules=yes
  • BEAKER_debug: show the commands being run on the STU and their output.
  • BEAKER_destroy=no: prevent the machine destruction after the tests finish so you can inspect the state.
  • BEAKER_provision=no: prevent the machine from being recreated. This can save a lot of time while you're writing the tests.
  • BEAKER_use_fixtures_dir_for_modules=yes: cause all module dependencies to be loaded from the spec/fixtures/modules directory, based on the contents of .fixtures.yml. The contents of this directory are usually populated by bundle exec rake spec_prep. This can be used to run acceptance tests to run on isolated networks.