STIG Checklist Generator Puppet Module
- ReadMe
- Reference
- Changelog
Table of Contents
Description
This utility generates STIG checklist files by pulling data from puppetdb. It requires KGI STIG module(s) to be deployed to the target node(s) because the modules collect facts that supply the status of the respective STIG findings. An optional YAML file may be used to override checklist fields that would otherwise be populated by the automation data. This module is also used to enable the Puppet and Splunk integration for the STIG Compliance solution. This module will install and configure all of the components that are needed on a target node. This should be deployed to a Linux based machine running RHEL 7/8 or CentOS.
Setup
What stig_checklist affects
The module will install the 'python-requests' and 'PyYAML' packages that are used to make connections to the puppetdb API endpoints. The installation directory is defined by the 'install_dir' parameter and is where the remaining files will be installed. Ensure the parent directory already exists (or manage it as a separate puppet resource).
Files that are installed under the 'install_dir':
checklist.py - The script that generates STIG checklist files
config.yaml - This file configures the URL for puppetdb
templates - Subdirectory that contains "blank" STIG checklist files used as templates
overrides - Subdirectory contains optional YAML files to override automation findings in reports.
checklists - Subdirectory that will contain generated checklist files. This directory will only be managed by Puppet when $splunk_integration is true, and in this case the directory owner will be set to $splunk_user. When Splunk integration is not enabled the 'checklist.py' script will create the 'checklists' subdirectory if it is not present.
processed - Subdirectory that is only managed by Puppet when Splunk integration is enabled. The Splunk TA will move files here from "checklists" after parsing the data and sending to Splunk.
Setup Requirements
Puppet server infrastructure is required, including puppetdb. One or more STIG modules from KGI must be deployed and run at least once on the target node(s) so the report data is available in puppetdb.
This utility itself must be run from a managed puppet node because it relies on the puppet certificate to authenticate with puppetdb. Ensure any host firewall running on puppetdb is configured to permit access from the node being used to generate checklists, or just run the utility on the puppetdb host directly.
When running reports with Puppet Enterprise where the reporting node is not puppetdb server, you may (depending on your configuration) need to add the certificate for the reporting node(s) to '/etc/puppetlabs/puppetdb/certificate-allowlist'. Changing this file requires restarting the 'puppetdb' service.
Usage
You will likely need to assign the 'puppetdb_url' parameter when deploying the module. This is the path that the reporting node will use to access puppetdb, and defaults to 'https://puppet:8081'.
The default installation directory is '/opt/stig_checklist', but this may be changed with the 'install_dir' parameter. Note that when using the "splunkforwarder" module with the optional TA support to index STIG checklists into Splunk that "${install_dir}/checklists" should be the source directory, and "${install_dir}/processed" should be the destination.
@example
class { 'stig_checklist':
puppetdb_url => 'https://puppetdb.mydomain.com:8081',
}
Once the module has been applied to a node you can generate STIG checklists for any puppet node that has supported KGI STIG modules assigned. Generate a report by referencing the target node by the full certificate name as used by puppet:
cd /opt/stig_checklist
./checklist.py -n mynode.mydomain.com
Alternatively, you can generate checklist for all nodes using '-a' or '--all'. This will request all nodes from puppetdb that have a supported STIG module assigned and build a checklist file for each one:
cd /opt/stig_checklist
./checklist.py -a
Splunk integration
Set the 'splunk_integration' parameter to true to enable integration with Splunk. This is normally only required to be set for a single node that will generate reports for all managed nodes. The reporting node should also have the "splunkforwarder" Puppet modules installed and configured to use the TA for STIG indexing. See that module's documentation for details.
Limitations
This has been tested on CentOS/RedHat 7 but should work from most other Linux distributions.
Table of Contents
Classes
stig_checklist
: Install STIG checklist generation components
Tasks
new_ckl
: Generate a STIG checklist for a single node or all nodes.
Classes
stig_checklist
Install STIG checklist generation components
Examples
class { 'stig_checklist':
puppetdb_url => 'https://puppet.mydomain.com:8081',
}
Parameters
The following parameters are available in the stig_checklist
class:
install_dir
Data type: String
The directory where reporting components will be installed. The parent directory must exist or the resource will fail. When installing in conjunction with the Atlas Splunk TA, the source directory for the TA should point to "${install_dir}/checklists" and the destination directory should point to "${install_dir}/processed". Defaults to '/opt/stig_checklist'
puppetdb_url
Data type: String
The URL where the puppetdb API endpoints are available.
splunk_integration
Data type: Boolean
Enables a cron job to generate reports for all nodes per the schedule defined by 'report_schedule'. Also ensures that the report files are owned by 'splunk_user' so the TA will be able to process and archive files.
stig_report_schedule
A hash that defines the schedule for reporting STIG data to Splunk. Hash key names are the keywords for a typical 'cron' resource: 'hour', 'minute', 'month', 'monthday', and 'weekday'. Values must be valid for a cron resource. Default schedule is daily at 0230.
splunk_user
Data type: String
When Splunk integration is enabled, the owner of generated reports will be changed to this user to allow the Atlas TA to process and move the checklist files. Default is 'splunk'
splunk_group
Data type: String
When Splunk integration is enabled, the group owner of generated reports will be changed to this user to allow the Atlas TA to process and move the checklist files. Default is 'splunk'
report_schedule
Data type: Hash
Tasks
new_ckl
Generate a STIG checklist for a single node or all nodes.
Supports noop? false
Parameters
node
Data type: String[1]
The target node name, or keyword 'all'.
install_dir
Data type: Optional[String[1]]
The full directory name where 'checklist.py' is installed.
Changelog
Release 0.4.0
- Updated to support RHEL7 STIG v3r4
- Updated to support RHEL8 STIG v1r3
Release 0.3.1
- Remove Splunk forwarder support in favor of the module dependency for kgi/splunkforwarder
- Generate and use a new UUID when generating STIG checklists
- When Splunk integration is enabled, manage the data directories and ensure that the file owner of the directories and checklist files is $splunk_user to support the Atlas Splunk TA.
Release 0.3.0
- Updated to support RHEL7 STIG v3r3
- Requires version '0.3.0' of the KGI 'rhel7stig' module
- Refactored "checklist.py" to eliminate duplicate code and reduce calls to puppetdb
Release 0.2.0
- Updated to support RHEL7 STIG v3r2
- Now uses custom facts from puppetdb to populate status and details.
- Requires version '0.2.0' of the KGI 'rhel7stig' module
Release 0.1.0
Initial release with support for RHEL7 STIG v3r1
Bugfixes
N/A
Known Issues
N/A