step CLI, A Root, A Leaf, A Chain Verified And One Refused

step on EL 10 from the GitHub release; get_url refuses it unless its SHA-256 is in the vendor's checksums file, and the live test re-checks it, then creates a root CA and a leaf offline, verifies the chain against the right root, sees it refused against another, and inspects the leaf as JSON. The client half of the step-ca role. Pinned. Original role, live-tested on Rocky Linux 10.

This is the operations reference: version drift, dependants and neighbours. For what the module provisions, its inputs and outputs, and how to buy it, see the catalogue entry.

ansibleMulti-cloud & platform-agnosticSecrets & KMSv1.0.0live-tested

Provider drift

This artifact declares no Terraform provider requirements, so there is nothing to drift. Provider freshness applies to Terraform and OpenTofu modules.

What depends on this

No reference architecture names this module, so changing it affects only configurations that reference it directly.

Nearest alternatives

Same cloud, same category. These are what you would weigh against it without changing provider.

A KV v2 Engine that Keeps Versions and Refuses Blind Overwrites A Private CA that Issues from the Intermediate with Roles Bound to Domains AppRole Roles that Bind to Somewhere Specific and Issue Secret IDs that Expire CFSSL, A CA Minted And Read Back Dynamic PostgreSQL Credentials with the Root Password Rotated Away OIDC Auth Whose Roles Admit the Claims You Name OpenBao Server With Integrated Storage, Initialised In The Lane Transit Keys that Rotate and Cannot Be Deleted or Exported

The same job on other clouds

This module has no cross-cloud peer set in the catalogue, so there is no portability comparison to draw.

Installing it

module "ansible_step" {
  source  = "www.iac-bazaar.com/iac-bazaar/ansible-step/any"
  version = "1.0.0"
}

A registry token is required for the download itself. Installing through the registry protocol has the two credential steps.