An Ansible role for installing, running, and removing Goss from a system without any traces.
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
callback_plugins
defaults
files
library
meta
tasks
tests
.gitignore
.travis.yml
LICENSE
Makefile
README.md
Vagrantfile
ansible.cfg
requirements.yml
vagrant.yml

README.md

ansible-role-degoss Build Status

Installs, runs, and removes Goss and one or more Goss spec file(s) on a system. If you'd like to lint a system without leaving many "traces,"1 degoss should do what you want.

Props to upstream ansible-goss for inspiration for the module and first steps.

Available on Ansible Galaxy at naftulikay.degoss.

Requirements

This module downloads a 64-bit Linux Goss binary. If support for multiple operating systems and architectures is desired, pull requests are welcome!

Role Variables

Here is a sampling of valuable role variables that may be of interest to the user.

Degoss Variables

Variables for configuring the degoss role.

degoss_debug
Booleanish value that decides whether to output debug information or not. Defaults to false.
degoss_clean
Booleanish value that decides whether to clean all Goss binaries and tests from the machine after the run. Defaults to true, which means that by default, `degoss` will remove all traces from a machine after finished. Set to false to enable caching the Goss binary on the machine.
Goss Variables

Variables affecting the runtime of Goss.

goss_file
A Goss test file to run on the target machine.
goss_addtl_files
Additional Goss test files to copy to the machine.
goss_addtl_dirs
Additional directories containing Goss test files to copy to the machine, recursively.
goss_version
The version string of Goss to install, or latest. Example: 0.2.5.
goss_env_vars
A dictionary of environment variables to set during Goss execution.

Dependencies

None.

Example Playbooks

Single Test File

Fetches the latest version of Goss and executes the tests/goss.yml file.

---
- name: test
  hosts: all
  roles:
    - { role: degoss, goss_file: tests/goss.yml }

Pinned Version

Downloads a specific version of Goss and executes the tests/goss.yml file.

---
- name: test
  hosts: all
  roles:
    - { role: degoss, goss_version: 0.2.5, goss_file: tests/goss.yml }

Multiple Files and Directories

Executes goss.yaml, uploading the tests directory and some other files:

---
- name: test
  hosts: all
  roles:
    - role: degoss
      goss_file: goss.yaml
      goss_addtl_files: [include.yml]
      goss_addtl_dirs: [tests/]

Environment Variables

Executes goss.yml, passing in the given environment variables:

---
- name: test
  hosts: all
  roles:
    - role: degoss
      goss_file: goss.yml
      goss_env_vars:
        distro: "{{ ansible_distribution | lower }}"

In this case, distro will be available to Goss at runtime at {{.Env.distro}}.

License

MIT


Footnotes:

  1. If you're really so dense as to assume that you can use this to maliciously execute code on arbitrary systems, there are a number of problems with this assumption:
    1. Ansible itself is a remote-code-execution framework. That's what it is, that's what it does.
    2. Ansible is poor at doing things maliciously because by default, activity is logged via sudo and syslog. If the machine is forwarding syslog elsewhere, you're caught.
    3. Ansible, having been designed as an automation and configuration management system for systems administrators, is likely to try to leave auditable traces because this is a common use case for companies attempting to answer security audit questions.