> ## Documentation Index
> Fetch the complete documentation index at: https://docs.internal.nscale.com/llms.txt
> Use this file to discover all available pages before exploring further.

# HashiCorp Vault

> The HashiCorp Vault KV the site-standup CLI writes Fleet Manager secrets into.

* **Kind:** Dependency
* **Version:** 3
* **Fleet Manager owner:** Fleet Manager squad, #fleet-manager-chat (individual claimant pending)
* **Counterpart owner:** unassigned, SRE (secrets platform)
* **Last reviewed:** 2026-09-18

## What flows

Two paths touch [Vault](../start-here/glossary#vault). At site standup, `fleetctl deployment-standup`
(`src/fleet_manager/cli/commands/deployment_standup/`) writes a new site's Fleet Manager secrets into the
`fleet-manager` KV path on `https://vault.nscale.com` under the operator's own Vault session, alongside the
matching [1Password](../start-here/glossary#1password) writes. At runtime, Vault is the hop that carries [NATS](../start-here/glossary#nats) client certificates between namespaces:
cert-manager issues them in the `nats` namespace, a `PushSecret` writes each one to the `fleet-manager` mount at
`<env>/hub/nats/<client>/client-tls`, and an `ExternalSecret` materialises it back into the `fleet-manager` namespace
(see [nats](./nats)); both refresh hourly, so a renewed certificate takes up to two hours to reach the pod. The hub
chart's `product-vault-store` SecretStore (the `product-approle` AppRole) now exists only for the Borneo
connector's GCP credentials and renders only when that ExternalSecret is enabled. Application secrets still
come from 1Password (see [onepassword](./onepassword)), which an SRE-owned sync populates from Vault; whether Fleet
Manager should read those directly from Vault is an open decision.

## What breaks if this changes

A change to the KV path, policy or auth method fails site standup at the secret-write step for the operator running
it. A missing Vault secret or a failed ExternalSecret refresh blocks the rollout of the connectors and publisher
that take their NATS certificates from Vault, even while 1Password is healthy. Running sites are otherwise
unaffected until the Vault-to-1Password sync stops delivering rotated secrets.

## Enforcement

* **Principal:** the operator running the CLI at standup; the PushSecret and ExternalSecret identities of the NATS
  chart at runtime; the shared `product-approle` AppRole for the Borneo GCP credentials.
* **Mechanism:** `vault login -method=oidc` (or another enabled method) producing a token with the `fleet-manager` KV
  permissions for the CLI; PushSecret and ExternalSecret pairs for the NATS certificates; one ExternalSecret against
  `product-vault-store` (`deployment/charts/hub/templates/google-borneo/vault-product-secret-store.yaml`) for the
  Borneo GCP credential.
* Runbook: `src/fleet_manager/cli/commands/deployment_standup/README.md`.

## Gaps

* No Fleet Manager-specific service identity in Vault; standup depends on a human session and runtime shares the
  product AppRole.
* The sync into 1Password and its failure signals are owned outside this repository.

## Change log

* 2026-09-18 v3: `product-vault-store` is Borneo GCP only; the NATS rollback path through it was removed from the
  hub chart (FLEET-2692).
* 2026-09-16 v2: NATS certificates now flow through the `fleet-manager` mount; `product-vault-store` is rollback and
  Borneo GCP only.
* 2026-09-09 v1: created; describes present behaviour.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.