blastwall

Why IdM Matters

IdM can look like a login database if you only see usernames and hostnames. Blastwall uses it as a records system for privileged automation: who the automation identity is, which hosts are in scope, what login path is allowed, which SELinux badge the session receives, what sudo may delegate, and which verified coverage marker AAP can read before launch.

That record chain matters because SELinux enforcement happens on the managed host, but the decision to send automation there happens earlier. I want AAP to see enough central state to avoid launching a sensitive workflow at a host that is missing the expected identity, access, mapping, or coverage.

Dispatch Analogy

I use one analogy throughout: dispatched work to a controlled job site. The job terms make the control chain easier to follow; each row ends with the actual Blastwall dependency.

That keeps the parts in their natural lanes. AAP does not become an IdM parser. IdM does not author SELinux policy. SELinux does not know about Controller workflow intent. Each system contributes the control it is already good at.

The IdM Records

The IdM model is deliberately ordinary. Blastwall does not need an exotic identity shape; it needs a consistent relationship between the automation identity, the managed host, and the SELinux user map.

Real Object Map

The analogy is only a warmup. This table maps the job-site language back to the current lab object names.

Concrete Walkthrough

In the lab, think of svc-ansible-runner as the automation crew and mirror-registry.workshop.lan as the job site. A valid Blastwall run needs the following chain to line up:

1. The automation identity is a member of the Blastwall automation group.
2. The managed host is a member of the Blastwall managed-host group.
3. The HBAC rule says that identity may enter that host through SSH.
4. The SELinux user map says the login receives blastwall_u:s0.
5. The sudo rule allows the delegated root work the workflow needs.
6. The verified host marker says the expected Blastwall policy coverage is present.
7. AAP preflight selects the host only when the records agree.

After login, the session can still become UID 0 through sudo, but it remains in blastwall_u:blastwall_r:blastwall_t:s0. That is the point of the model: central records shape the arrival, and host-local SELinux policy limits what the privileged automation subject can do after it arrives.

AAP Selection

The workflow should know whether a host is suitable before it starts the runtime proof. That suitability is not a single patched/unpatched bit. It is the combination of identity membership, host membership, HBAC, SELinux mapping, sudo policy, and optional coverage markers.

AAP asks which hosts are current
  -> eigenstate.ipa reads IdM state
  -> IdM returns identity, access, sudo, SELinux map, and marker state
  -> AAP selects suitable hosts
  -> SELinux enforces the mapped session

The host marker is only a claim AAP can read after verification writes it. It is useful for target selection, but it does not replace live HBAC, sudo, SELinux mapping, or runtime denial checks.

Runtime Boundary

After AAP selects the host, the local system still makes the decisive enforcement decision. SSSD and pam_selinux apply the IdM SELinux user map at login. Sudo can reach UID 0, but the session remains inside blastwall_u:blastwall_r:blastwall_t:s0.

AAP, IdM, and eigenstate.ipa do not perform the kernel denial. They make the arrival conditions explicit. The host-local SELinux boundary denies the exploit surfaces for that confined automation subject.

Failure Modes

Each failure points to a specific missing or weak record.

Where To See It

AAP Demo shows the Controller side: inventory sync, preflight, launch, node status, and job stdout. Ansible Demo shows the bootstrap side: IdM object creation, policy rollout, direct probe output, audit evidence, and self-protection.