audit_stuff.md

Ansible Controls and Audit Information

Overview of Ansible Use

• Ansible is run interactively by me under my own credentials.
• It cannot do anything beyond what my user can already do over SSH and sudo.
• It is used for:
  • Managing configuration files (for example /etc/security/access.conf)
  • Installing or updating packages
  • Restarting services
  • Other routine administrative tasks

Controls Around Ansible Use

• Playbooks are stored in my home directory, only accessible by me and root.
• Playbooks are also stored in Git, with pull requests for review.
• Change tickets are raised before work is done, then I run the tasks using my own access.
• There is no separate privileged automation account; actions are logged as my user in system logs.

Consistency and Protection

• Only I have access to the Ansible directories in my home folder (700 permissions).
• Playbooks are version controlled in Git.
• Consistency across environments comes from using the same playbooks and inventories.

How Changes Are Managed and Reviewed

• Logic (such as managing /etc/security/access.conf) is kept in a playbook under roles/<role_name>/tasks/.
• Edits to playbooks go through Git pull requests for review.
• Change tickets are raised and tracked before execution.

Execution Logs

Because Ansible runs as my user, normal system logs apply.

SSH logins:

sudo grep sshd /var/log/secure


## Sudo Commands
These show timestamp, user, and commands run with sudo:

sudo ausearch -m USER_CMD -ts today sudo grep COMMAND /var/log/secure

## List of Playbooks in Roles

List every task file under your roles:

find roles -type f -path "roles//tasks/.yml" find roles -maxdepth 1 -mindepth 1 -type d -printf '%f\n'

### Show template or task in playbooks:

cat roles/<role_name>/templates/access.conf.j2 cat roles/<role_name>/tasks/main.yml | grep access.conf -A3 -B3

## List of Playbooks in Roles

List every task file under your roles:

find roles -type f -path "roles//tasks/.yml" find roles -maxdepth 1 -mindepth 1 -type d -printf '%f\n'

## Versioning and Approval Records

- Git pull requests and commit history serve as version history and approval.  
- Change management tickets exist in our ticketing system.  
- There is no separate Ansible approval workflow beyond that.  

## Key Talking Points

- Ansible does not bypass controls; it uses my user’s access.  
- All actions are logged through normal SSH and sudo mechanisms.  
- Playbooks live in a directory only I and root can access.  
- Playbooks are also stored and tracked in Git, with pull request reviews.  
- Configuration consistency is maintained by using the same playbooks across environments.  
- Example configuration (`/etc/security/access.conf`) can be shown live.