# One machine that becomes a mesh, runs the mesh's own certificate authority, and is then given the
# module that makes it trust it — the bed for novox/hq ADR 0147 and issue 129.
#
# The question is narrow and the bed is shaped to answer only it: does a machine holding `ca-trust`
# verify a certificate from the mesh's own authority with no bundle argument and no `-k`, and does
# it stop verifying it when the module is taken away? The authority itself is what is dialled —
# step-ca serves its own API with a leaf it issued — so nothing else has to be right for the answer
# to mean something. No proxy, no routed name, no public issuance: those are the certificates and
# route-forwarding beds, and a trust bed that leaned on them would pass for their reasons.
#
# The negative half is not optional. It is asserted BEFORE the module is assigned and again AFTER it
# is unassigned, because an anchor bed that only ever checks the success is one that would pass on a
# machine that already trusted everything.
#
#   MESH_LAB_HOST_BINARY=.../mesh-host   MESH_LAB_BUNDLE=.../examples/foundation-first-node.lock
#   MESH_LAB_CATALOG=.../mesh-catalog/modules
#   step-ca's image is upstream and pinned by the catalogue; the machine pulls it over its uplink.
#   ca-trust carries no image at all — a script, a unit, and the machine's own systemd.
scenario: trust-anchor

segments:
  hosting:
    kind: public
    cidr: [192.0.2.0/24]

machines:
  anchor:
    at: { segment: hosting, address: [192.0.2.10] }
    egress: true
    inbound: allow
    memory: 3GiB
    cpus: 2

images:
  - mesh-controller:development

place:
  # Only the host. The authority's image comes from the internet over the machine's uplink, and the
  # trust module has nothing to place.
  all: [host]