vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

docs: clear write-good.Passive hits in docs/getting-started/setup.md

Browse source 
5 genuine passive-voice rewrites (actor named — pkcs11, the operator,
the minting policy; one converted to a runbook imperative; one
converted to an active 'gate on' verb); 5 false positives left
untouched — predicate-adjective necessity/security-property
descriptions ('is needed', 'is stored', 'is authenticated', same
category as the already-established 'is required'), a
project-tracking-state description ('is tracked'), and a topology
claim with no single correct actor to name ('is generated where it's
read' — which component mints a given credential varies per row in
the credentials table).
This commit is contained in:
iris 2026-09-20 04:51:33 +02:00 • committed by mara
commit f6756de925
1 changed files with 8 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

16
docs/getting-started/setup.md
View file

@ -145,7 +145,7 @@ forgotten one expires rather than lingering.
A store bootstrapped by an earlier version has the policy, the auth method and
the role, but no `secret/` engine — the controller's first credential write
answers `no handler for route "secret/data/…"`. The bootstrap token can't fix it
either: the policy it was minted from names nothing under `sys/mounts`. Mount it
either: the policy that minted it names nothing under `sys/mounts`. Mount it
once with the root token from `init`:
```bash
@ -160,10 +160,10 @@ leaves it alone.
Whether anything more is needed depends on
`services.hyperhive.deploy.bao.seal`:
- **`pkcs11`** (the default) — the key is bound to the host's TPM and the
store unseals itself on every restart. `init` is the only manual step.
- **`shamir`** — no TPM, so `bao operator unseal` is needed again after
every restart, with the keys `init` printed.
- **`pkcs11`** (the default) — pkcs11 binds the key to the host's TPM, and
the store unseals itself on every restart. `init` is the only manual step.
- **`shamir`** — no TPM, so run `bao operator unseal` again after every
restart, with the keys `init` printed.
The store serves TLS, and on a hive that deploys it you need do nothing: a
first-boot unit mints a CA of the store's own plus the two leaves it signs —
@ -174,8 +174,8 @@ half, `.clientCertFile`, `.clientKeyFile` and `.serverCaFile` at the reader's.
Those are `mkDefault`s, so naming your own paths wins. Do that when your
certificates come from a real internal CA; the store has no opinion about
which. A hive that does **not** deploy the store names the reader's three
itself: that leaf is issued out of band, and it's the one credential the store
can't hand you, being what opens it. ⚠️ Not the gateway's HTTPS certificates and not the hive CA — this is
itself: the operator issues that leaf out of band, and it's the one credential
the store can't hand you, being what opens it. ⚠️ Not the gateway's HTTPS certificates and not the hive CA — this is
**mTLS between services and the store**, a separate trust domain, because a
store that took its identity from an authority it will itself distribute could
never come up before that authority.
@ -197,7 +197,7 @@ swarmctl user add mara --display-name Mara --email mara@example.com --group admi
```
⚠️ **Keep `--group admins`.** it's not decoration: operator-only
surfaces (the swarm UI below) are gated on that group, and an account
surfaces (the swarm UI below) gate on that group, and an account
without it authenticates successfully and is then refused — which reads
like a broken login rather than a missing group.