autonomy ros2 keystore init

Create an SROS 2 keystore root at

Synopsis

Initialize an SROS 2 keystore root at <dir>. Wraps:
  ros2 security create_keystore <dir>
  + governance.xml domain extension (#938 3-D)

The keystore root contains:
  enclaves/         per-node identity bundles (cert + key + permissions);
                    created later by 'autonomy ros2 keystore mint'.
                    governance.xml + .p7s here describe domain-wide
                    DDS-Security rules shared across all enclaves.
  private/          the trusted CA's private key. Treat as secret material.
  public/           the trusted CA's public cert; nodes verify chains against this.

The keystore directory is created if missing. init is IDEMPOTENT: if <dir>
already contains a keystore, it is REUSED (the CA is left untouched) and only
the --domain governance is re-applied — safe to re-run in a rebuild flow.
--force regenerates the CA from scratch (a fleet-wide restart — see --force).
'ros2 keystore mint' and 'permissions' are likewise safe to re-run.

#938 3-D: --domain (repeatable). The default governance.xml minted by
'ros2 security create_keystore' hard-codes a single DDS domain (id=0).
Any participant joining a different domain is rejected at DDS-Security
with "Could not find domain X in governance (code: 141)" — even with
correct permissions.xml on that domain. The bridge architecturally
needs non-zero domains (agent + real isolation). When --domain values
are supplied, this command rewrites governance.xml so its
<domain_rule>/<domains> includes every listed domain, then re-signs
governance.p7s against the keystore CA via openssl smime (same
S/MIME multipart format pinned by
TestResignPermissions_ProducesVerifiableSMIME for permissions.p7s).

Prereq: ros-humble-ros-base on the host (gives "ros2 security" on PATH).
When --domain is non-default, openssl must also be on PATH (for the
governance.p7s re-sign). Keystore creation is a host operation
(durable secret material lives on the operator's filesystem), so this
command runs native; the runtime image's ros2 security is still used
at runtime when the bridge consumes the keystore (3-B).

Examples:

  # Single-domain workload (default; governance covers domain 0 only):
  autonomy ros2 keystore init /var/lib/autonomyops/ks

  # Governed-bridge dual-domain (agent + real on the same keystore):
  autonomy ros2 keystore init /var/lib/autonomyops/ks --domain 42 --domain 99

Usage

autonomy ros2 keystore init <dir> [flags]

Options

      --domain id   id DDS domain ID(s) the keystore's governance.xml should cover (0..232). Repeat the flag for multiple domains. Empty (the default) keeps sros2's single-domain-0 default — usable for single-domain workloads. The governed bridge needs --domain for both agent + real domains, e.g. --domain 42 --domain 99 (#938 3-D).
      --force       regenerate the keystore CA even if one already exists at <dir>. WITHOUT --force, init on an existing keystore REUSES it (CA untouched — safe to re-run in a rebuild flow). --force wipes + regenerates the CA and all identity material, which invalidates every enclave a running participant is using — a FLEET-WIDE RESTART, not a live refresh. #1241.

Options inherited from parent commands

      --require-signed-manifest   Refuse to start if the SHA256SUMS release manifest or its cosign signature is missing/invalid (Tier 2 binary-integrity check; default: build-time compile-in via -ldflags -X, build-hardened artifacts=true, all others=false)

See also