eigenstate-ipa

AAP Integration

Related docs:

  VAULT/CYBERARK PRIMER     OPENSHIFT ECOSYSTEM PRIMER     OPENSHIFT RHOSO USE CASES     OPENSHIFT RHACM USE CASES     OPENSHIFT RHACS USE CASES     OPENSHIFT QUAY USE CASES     ROTATION USE CASES     INVENTORY USE CASES     EPHEMERAL ACCESS CAPABILITIES     DOCS MAP  

Purpose

This page explains how eigenstate.ipa fits into Ansible Automation Platform and Automation Controller.

The important boundary is simple: the collection is mostly controller-side. The execution environment talks directly to IdM. Managed hosts usually consume artifacts or decisions that were produced on the controller.

Use this page for:

Use plugin pages for exact options. Use use-case pages for full playbook detail. This page is the control-plane view.

Controller Model

flowchart LR
    ctrl["Controller job or inventory sync"] --> ee["Execution environment"]
    cred["Mounted keytab or password credential"] --> ee
    ee --> inv["idm inventory"]
    ee --> lookups["lookup plugins"]
    ee --> write["vault_write module"]
    inv --> idm["IdM / FreeIPA"]
    lookups --> idm
    write --> idm

The collection is strongest when AAP supplies:

That is the part of the stack that makes IdM-backed workflows feel operationally coherent instead of ad hoc.

Current Controller-Side Surface

Inventory

ipalib-backed lookups and modules

CLI-backed lookup

The official IdM collections still matter beside this surface. They remain the right place for enrollment, broad CRUD against IdM objects, and cert revocation. eigenstate.ipa is the read-heavy and workflow-focused layer around those operations.

Execution Environment Requirements

Surface EE requirements Notes
idm inventory python3-requests; python3-gssapi; python3-requests-gssapi or python3-requests-kerberos; krb5-workstation when keytab-driven kinit is used inventory does not require ipalib
vault, vault_write, principal, cert, otp, dns, user_lease, selinuxmap, sudo, hbacrule python3-ipalib; python3-ipaclient; krb5-workstation for ticket acquisition these share the same IdM Python stack
keytab package providing ipa-getkeytab; krb5-workstation on RHEL 10 this is ipa-client

[!IMPORTANT] Inventory can work while the ipalib-backed surfaces fail if the EE only contains the HTTP stack. That split is deliberate in the collection, so the EE image has to be deliberate too.

For most estates, the simplest stable Controller posture is one EE containing all three dependency groups.

Authentication Guidance

Prefer Kerberos with a mounted keytab.

Why:

Recommended pattern:

High-Value Controller Workflows

These are the combinations worth documenting and standardizing. They are the places where the collection becomes a coherent controller workflow instead of isolated plugin calls.

1. Identity-driven inventory sync

Use eigenstate.ipa.idm to make Controller inventory follow the IdM model instead of a second static host list.

High-value combinations:

Guardrail:

Read next: INVENTORY USE CASES

2. Pre-flight gate before changing systems

Use lookups on the controller before any managed host work starts.

Best combinations:

This is one of the collection’s strongest differentiated patterns. Vault and CyberArk can answer credential questions. They do not answer live IdM policy questions for a host, service, or login path.

3. Service onboarding

Use principal as the gate, then branch into the artifact you actually need:

This keeps identity state, key material, and cert issuance in one controller flow instead of scattering them across shell tasks.

Read next: PRINCIPAL USE CASES

4. Static secret lifecycle

Use vault_write for mutation and vault for retrieval. Let AAP supply the schedule, approvals, execution boundary, and credentials.

This is the correct answer to the collection’s rotation story:

Read next: ROTATION USE CASES

5. Host enrollment and first-day trust

Use otp to generate the enrollment credential, then hand the actual installation to the official IdM collections.

Best combination:

That keeps eigenstate.ipa on the credential-generation boundary it was built for instead of turning it into a full enrollment role.

6. Lease-like temporary access patterns

AAP can orchestrate temporary access, but it is not the only control. The stronger patterns are the ones where IdM itself makes the identity unusable after the window closes:

Read next: EPHEMERAL ACCESS CAPABILITIES

For the delegated user side specifically, continue to USER LEASE USE CASES.

7. OpenShift and OpenShift Virtualization workflows

When OpenShift uses Keycloak on top of IdM-backed trust, the collection’s value shows up around the cluster rather than in direct cluster CRUD.

The strongest controller-side patterns are:

Read next: OPENSHIFT ECOSYSTEM PRIMER.

8. RHACM-triggered remediation and lifecycle hooks

RHACM can trigger AAP from policy violations and lifecycle events. The useful pattern is that AAP owns the job, while IdM owns the identity, policy, and supporting-state boundary. RHACM hands off event context such as target_clusters, policy_name, and policy_violations; AAP turns that into a controller-side workflow; eigenstate.ipa checks whether the supporting state is actually ready.

In practice, that means RHACM-triggered jobs can use the same controller-side patterns already used elsewhere in the collection:

Read next: OPENSHIFT RHACM USE CASES.

9. RHACS-triggered security workflows

RHACS already owns policy evaluation, admission control, runtime detection, and notifier integrations. The valuable AAP pattern is not to duplicate those controls. It is to make the response path identity-aware.

In practice, that means RHACS-triggered jobs can use controller-side patterns such as:

Read next: OPENSHIFT RHACS USE CASES.

10. Quay-triggered registry and repository workflows

Quay already owns registry behavior, repository notifications, mirroring, and robot-account workflows. The useful AAP pattern is to make the surrounding automation path identity-aware instead of trying to turn Quay into a full workflow engine.

In practice, that means Quay-triggered or Quay-adjacent jobs can use controller-side patterns such as:

Read next: OPENSHIFT QUAY USE CASES.

11. RHOSO operator and tenant workflows

RHOSO already has its own operator-driven lifecycle, Keystone identity model, and RHEL data-plane relationship. The useful AAP pattern is the work around those boundaries rather than inside the product.

In practice, that means RHOSO-adjacent jobs can use controller-side patterns such as:

Read next: OPENSHIFT RHOSO USE CASES.

Example Patterns

Lean inventory source for Controller

plugin: eigenstate.ipa.idm
server: idm-01.corp.example.com
use_kerberos: true
kerberos_keytab: /runner/env/ipa/admin.keytab
verify: /etc/ipa/ca.crt
sources:
  - hosts
  - hostgroups
hostgroup_filter:
  - webservers
  - databases
host_filter_from_groups: true
hostvars_include:
  - idm_fqdn
  - idm_location
  - idm_hostgroups
keyed_groups:
  - key: idm_location
    prefix: dc
    separator: "_"

Controller-side policy gate before maintenance

- name: Pre-flight gate before privileged maintenance
  hosts: localhost
  gather_facts: false

  vars:
    target_host: app01.corp.example.com
    deploy_identity: svc-maintenance

  tasks:
    - name: Confirm sudo rule exists
      ansible.builtin.set_fact:
        sudo_rule: "{{ lookup('eigenstate.ipa.sudo',
                        'ops-maintenance',
                        sudo_object='rule',
                        server='idm-01.corp.example.com',
                        kerberos_keytab='/runner/env/ipa/admin.keytab',
                        verify='/etc/ipa/ca.crt') }}"

    - name: Confirm HBAC access would be granted
      ansible.builtin.set_fact:
        access_result: "{{ lookup('eigenstate.ipa.hbacrule',
                            deploy_identity,
                            operation='test',
                            targethost=target_host,
                            service='sshd',
                            server='idm-01.corp.example.com',
                            kerberos_keytab='/runner/env/ipa/admin.keytab',
                            verify='/etc/ipa/ca.crt') }}"

    - name: Assert policy is ready
      ansible.builtin.assert:
        that:
          - sudo_rule.exists
          - sudo_rule.enabled
          - not access_result.denied
        fail_msg: "IdM policy does not match the maintenance workflow boundary."

Scheduled static secret update

- name: Rotate a shared application secret
  hosts: localhost
  gather_facts: false

  tasks:
    - name: Generate replacement secret
      ansible.builtin.set_fact:
        new_secret: "{{ lookup('community.general.random_string', length=32, special=false) }}"
      no_log: true

    - name: Archive replacement in IdM vault
      eigenstate.ipa.vault_write:
        name: app-secret
        state: archived
        shared: true
        data: "{{ new_secret }}"
        server: idm-01.corp.example.com
        kerberos_keytab: /runner/env/ipa/admin.keytab
        verify: /etc/ipa/ca.crt
      no_log: true

Where The Official IdM Collections Fit

Use the official collections when the job is primarily object management rather than lookup-driven decision making.

Typical examples:

Use eigenstate.ipa when the job is primarily:

Guardrails

To keep the docs and the workflows clear:

This site is open source. Improve this page.