Skip to content

straysheep-dev/ansible-configs

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

ansible-configs

ansible-lint workflow shellcheck workflow

A collection of ansible roles.

Note

This repo started after seeing IppSec's parrot-build and wanting to make my own bash scripts more reliable and scalable.

The notes that were previously below are now maintained on my blog entry focused on Ansible usage in general, while this README will cover interacting with this repo specifically. That post will be updated regularly with new notes.

Cloning

Each role is being split off into its own repo (submodule) for easier maintenance and CI with molecule.

To clone everything, recursively:

# Clone this monorepo
git clone git@github.com:straysheep-dev/ansible-configs.git

# Pull in the latest pinned commits from all submodules
git submodule update --init --recursive

Modifying

In most cases all you need to change are the roles, groups, and vault information you're using. You can (and should) have multiple playbooks, inventories, and to a lesser extent, vaults, as a way to maintain states of various groups of machines.

Tip

Example Files

  • playbook.yml is an example playbook with comments documenting usage
  • debug.yml is for debugging and developing individual tasks in isolation
  • auth.yml is a plaintext sample of a vault file
  • inventory/ has .ini and .yml examples and documentation for building inventories

OpenSCAP Utils

The inventory_openscap_utils folder has it's own README.

It's effectively a set of scripts that provide a way to download and customize the existing Ansible playbooks related to STIG, CIS benchmarks, PCI-DSS, (and more) for system hardening without reinventing or needing to maintain forks of them. The reason here is, applying them without any modification will completely break a system in most cases. They're meant to be modified on a case-by-case basis for the system and environment. Custom forks were tried originally, but these playbooks are complex enough that this was necessary and has been a much easier way to maintain ready-to-use custom playbooks.

This is only possible due to Ansible tags, as the OpenSCAP playbooks tag all of their tasks. This makes it easy to tune and customize the existing playbooks available in the ComplianceAsCode/content project.

License

MIT

About

A collection of ansible roles.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages