Inspect sudo policy
When To Use This
Use this when sudo rules, commands, or command groups should be reviewed before privileged automation.
Required Authority
IdM owns sudo policy. The lookup reads rules and related objects.
Safety Boundary
This workflow is read-only. Confirm that this is the intended boundary before placing it in a scheduled job or AAP workflow.
Inputs
- Named target objects
- Credentials with the required IdM or platform authority
- A reviewed output path or downstream task
Steps
- Confirm the target objects and authority before running.
- Run the command or task with review-friendly output.
- Inspect the returned evidence before continuing to any mutating step.
lookup('eigenstate.ipa.sudo', 'deploy-web', sudo_object='rule', result_format='record')
Example Sudo Policy Check
This playbook reads a sudo rule and asserts that the command expected by the deployment is represented in IdM.
inspect-sudo.yml
---
- name: Inspect sudo policy before relying on it
hosts: localhost
gather_facts: false
tasks:
- name: Read the maintenance sudo rule
ansible.builtin.set_fact:
sudo_rule: >-
{{ lookup('eigenstate.ipa.sudo',
'ops-maintenance',
sudo_object='rule',
server='idm-01.example.com',
kerberos_keytab='/runner/env/ipa/automation.keytab') }}
- name: Require systemctl access in the rule
ansible.builtin.assert:
that:
- "'/usr/bin/systemctl' in sudo_rule.commands"
fail_msg: "ops-maintenance does not allow systemctl."
Run It
ansible-playbook inspect-sudo.yml
Expected Evidence
The lookup returns the rule payload so you can validate command allow-lists before privileged execution.
{
"changed": false,
"exists": true,
"enabled": true,
"commands": [
"/usr/bin/systemctl",
"/usr/bin/journalctl"
],
"usercategory": "all",
"hostcategory": "all",
"hostgroup": []
}
Troubleshooting
- Permission failure: verify the account and delegated authority.
- Unexpected empty result: verify target names and source records.
- Unsafe output: redact payloads and add
no_log: truewhere secret material is present.