How-to

Distinguish IdM reachability from KRA-backed vault readiness.

Boundary

Preflight

Authority

idm, collection

Evidence

command-output

KRA-aware vault health

IdM LDAP host and policy data can be reachable while vault operations are not. Vault payloads depend on the KRA-backed vault plane, so preflight checks should target the server that the workflow will use.

- name: Check vault health on an explicit server
  eigenstate.ipa.vault_health:
    server: idm-01.example.com
    kerberos_keytab: /runner/env/ipa/automation.keytab
    ipaadmin_principal: automation@EXAMPLE.COM
    verify: /etc/ipa/ca.crt
    shared: true
    canary_vault: automation-health-canary
    canary_max_age_seconds: 3600
    require_direct_kra: true
  register: vault_health

The result separates planes:

changed: false
idm_reachable: true
vault_reachable: true
kra_available: true
canary_present: true
canary_age_seconds: 42
canary_stale: false
failure_class: none

Failure classes are intended for branching:

none
auth
ca
ldap
kra_unavailable
vault_not_found
timeout
scope_mismatch
unknown

vault_health does not validate vault replication consistency or payload freshness beyond the canary fields it can observe. It shows that the selected request path can authenticate, reach IdM, and run KRA-backed vault operations.

Release gate

Validate in the lab against a KRA-enabled server and, when available, a server that cannot complete vault operations directly:

ansible-playbook -i localhost, -c local - <<'EOF'
- hosts: localhost
  gather_facts: false
  vars:
    server: idm-01.example.com
    ipaadmin_principal: automation@EXAMPLE.COM
    shared: true
    canary_vault: automation-health-canary
    canary_max_age_seconds: 3600
    require_direct_kra: true
  tasks:
    - name: Check vault health on an explicit server
      eigenstate.ipa.vault_health:
        server: "{{ server }}"
        kerberos_keytab: /runner/env/ipa/automation.keytab
        ipaadmin_principal: "{{ ipaadmin_principal }}"
        verify: /etc/ipa/ca.crt
        shared: "{{ shared }}"
        canary_vault: "{{ canary_vault }}"
        canary_max_age_seconds: "{{ canary_max_age_seconds | int }}"
        require_direct_kra: "{{ require_direct_kra }}"
      register: vault_health
EOF

Capture the server, principal, CA path, KRA topology, canary result, and any negative-test failure class.

Live validation captured this evidence against a KRA-enabled IdM server. The server name is sanitized for publication:

{
  "kra_topology": "KRA server role present on idm-01.example.com",
  "server": "idm-01.example.com",
  "vault_health": {
    "canary_present": true,
    "failure_class": "none",
    "idm_reachable": true,
    "kra_available": true,
    "vault_reachable": true
  }
}