feat: make the DPU bootstrap CA operator-configurable

[chet]

Operators should be able to provide the CA that DPUs trust during provisioning without coordinating a flag-day deployment. This lets sites pin a long-lived Forge root for certificate rotation, while unconfigured sites retain today's CA download behavior.

What this involves

• Model the non-DPF DPU bootstrap CA source as a typed policy covering legacy_download, embedded, and mounted. No setting means legacy_download, so upgrading NICo does not require an accompanying site-config change.
• Keep host Scout boots outside that DPU policy. The source is passed only to DPU BFB/cloud-init provisioning.
• Make embedded an explicit site-build facility: BOOTSTRAP_CA_PATH stages a validated CA bundle at a dedicated BFB path, with no repository or developer-certificate fallback. Generic and SA builds retain their existing behavior.
• Keep mounted distinct from the embedded path so a missing operator-provided bundle fails closed instead of silently consuming artifact material.
• Separate the CA served by nico-pxe at /api/v0/tls/root_ca from the CA it uses for outbound API TLS. The new payload path falls back to FORGE_ROOT_CAFILE_PATH, preserving current deployments.
• Give the nico-pxe Helm chart an optional ConfigMap/Secret-backed CA mount. Leave it out of rendered deployments unless configured.
• Let DPF override the legacy download URL or receive its CA from a ConfigMap/Secret, while keeping the existing bare init-container invocation compatible. The shared published dpu-agent image does not embed a site trust anchor.
• Validate downloaded and mounted DPF bundles before atomically installing them, with no fallback between configured sources.
• Cover the legacy default and each opt-in mode with unit, shell, and Helm-rendering tests, plus documentation for rotation, configuration, staged rollout, existing-machine behavior, and server-chain verification.
• Keep end-to-end authentication and signing of the wider boot chain as separate follow-up work. These controls select the API server trust anchor; they do not claim to authenticate DHCP, DNS, iPXE, user-data, or replaceable boot artifacts.

[ajf]

How do we break the circular dependency of downloading certificates used to trust endpoints while likely not have initial trust? They would have to be downloaded over an insecure channel (either http directly or ignoring the server cert on https), thus being trivially susceptible to man-in-the-middle of the initial CA bundle fetching and an attacker being able to inject CA roots that become trusted.

We have this issue today, too, to be fair (look at the cloud-init for the DPU, for instance).

Make the boot artifacts usable as trust sources: explicitly include the Forge root in Scout and BFB builds, preserve it into installed BFB systems, and do not overwrite it when embedded mode is selected.

We can only do this if (a) we don't ship binaries (same trusted CA on every install of NICo would be a disaster), and (b) if the build provides the CA bundle at build time, it can't be put in the repository. It also doesn't solve the initial trust problem if an attacker can write a new BFB/Scout image.

This seems pretty over engineered though we probably just need a "Download CA Bundle URL" made available somewhere (kernel command line argument or something) where the CA can be hosted wherever.

Keep in mind we're working on deprecating/removing mTLS client auth so I assume this whole issue is talking about server trust validation and not mTLS validation of the client cert.

[chet]

@ajf Thanks for the eyes. Yeah -- this is server trust validation, not client-cert authentication, so removing mTLS client auth doesn't remove the DPU's need to authenticate nico-api. The legacy download remains the default; non-DPF already gets its PXE base from pxe_uri, DPF now has a full URL override, and the bundle behind /api/v0/tls/root_ca can be configured independently. Updated the shared-artifact side -- embedded now requires an explicit site BFB build input, SA behavior is unchanged, the published DPF image no longer carries the repository root, and DPF's no-image-fork path is a mounted Secret/ConfigMap. This still depends on artifact/boot-chain integrity, so we're keeping that limitation explicit. PTAL, thanks!