57_WolveandClaude Opus 5
f8c839a163
2.5.5 was two releases behind. Verified against the openbao/openbao source at
tag v2.6.2 that the bump is safe for an existing vault: raft's on-disk format
is unchanged (identical bbolt / hashicorp-raft / raft-boltdb pins,
byte-identical physical/raft/types.proto), snapshots restore in both
directions, and every stanza this config.hcl uses still parses -- the config
parser only moved import paths and the listener diff is additive.
Three corrections that came out of that check.
deploy.sh's printed crash-loop recovery command was already broken by 2.6.0.
That release adds `USER openbao` to the alpine image, so the container no
longer starts as root; the `docker run ... --entrypoint sh ... chown` it tells
the operator to run now executes as uid 100 and fails. Added `--user 0:0`, and
dropped the stale 2.5.5 literal from the same string. The detection logic
itself is unaffected -- `id -u openbao` still reads /etc/passwd and still
returns 100, verified by extracting the passwd layer from both published
images -- so a02524a holds and the volume does not need re-chowning.
The mlock story was wrong, and was already wrong on 2.5.5. OpenBao removed
mlock support: its own config parser carries "OpenBao has dropped support for
mlock. Please remove the line disable_mlock = false from your config and
disable or encrypt swap instead." So `cap_add: [IPC_LOCK]` and
`ulimits: memlock: -1` are inert, and config.hcl's "mlock keeps key material
off swap -- REQUIRED" was describing something that does not happen. The
BEHAVIOUR was right all along, because deploy.sh disables swap, which is the
actual mitigation; only the explanation was wrong. Corrected in config.hcl,
docker-compose.yml and the README. The two compose settings stay: they are
harmless, and removing them would recreate every deployed container for no
gain.
The built-in `seal "pkcs11"` stanza is deprecated in 2.6.0 for removal in
v2.7.0, and the HSM distribution is discontinued by then; PKCS#11 auto-unseal
continues only via the external `plugin "kms" "pkcs11" {}`. Noted where the
commented-out stanza lives, since a stack relying on it has to move before
taking 2.7.x.
Also worth recording and NOT acting on: do not switch to the openbao-distroless
image variant. It ships no shell, which breaks every `docker compose run
--entrypoint sh` probe deploy.sh uses.
Upgrading a LIVE vault is not automatic -- snapshot first, and the restart
comes back sealed. That is the next commit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
65 lines
3.2 KiB
HCL
65 lines
3.2 KiB
HCL
# OpenBao — hardened, same-LAN tape-encryption key store for Kanrisha.
|
|
#
|
|
# Native TLS on the listener (no reverse proxy in front), integrated raft
|
|
# storage (clean snapshot-based DR). This vault is the SOLE
|
|
# recovery path for encrypted tapes — losing the OpenBao data AND the unseal
|
|
# material loses every encrypted tape. Back it up (raft snapshots) and store the
|
|
# unseal keys/root token out of band (see the README + DR runbook).
|
|
|
|
storage "raft" {
|
|
path = "/openbao/data"
|
|
node_id = "openbao-1"
|
|
}
|
|
|
|
# TLS-terminating listener. tls.crt/tls.key are self-signed by deploy.sh on first
|
|
# run, or a CA-signed pair you drop in ./tls (e.g. issued by your Smallstep CA
|
|
# over ACME — see the README). The Kanrisha daemon trusts this via
|
|
# [encryption.openbao].ca_cert.
|
|
listener "tcp" {
|
|
address = "0.0.0.0:8200"
|
|
tls_cert_file = "/openbao/tls/tls.crt"
|
|
tls_key_file = "/openbao/tls/tls.key"
|
|
# Optional mTLS — require + verify a client cert from the tape host:
|
|
# tls_require_and_verify_client_cert = true
|
|
# tls_client_ca_file = "/openbao/tls/client-ca.crt"
|
|
}
|
|
|
|
# Keeping key material off disk is done by DISABLING SWAP (deploy.sh does this),
|
|
# NOT by mlock. OpenBao removed mlock support: its own config parser carries the
|
|
# message "OpenBao has dropped support for mlock. Please remove the line
|
|
# \"disable_mlock\" = false from your config and disable or encrypt swap instead."
|
|
# So do NOT add a disable_mlock line of either value -- `disable_mlock = false`
|
|
# is a hard startup error. cap_add: [IPC_LOCK] and ulimits memlock in
|
|
# docker-compose.yml are inert leftovers.
|
|
|
|
# Single-node raft: advertising 127.0.0.1 is fine because a lone node is always
|
|
# ACTIVE and never redirects clients (they connect straight to the LAN address).
|
|
# For HA / multiple nodes, set BAO_API_ADDR + BAO_CLUSTER_ADDR to each node's
|
|
# reachable LAN address in the compose env instead.
|
|
api_addr = "https://127.0.0.1:8200"
|
|
cluster_addr = "https://127.0.0.1:8201"
|
|
# The built-in web UI. Substituted by deploy.sh from OPENBAO_UI. It adds NO new
|
|
# exposure: it is served on this same listener, and anything reachable on :8200
|
|
# can already do everything through the API. Turning it on is what lets an
|
|
# operator initialise/unseal and log in from a browser, so the unseal keys are
|
|
# shown in the browser instead of a server shell's scrollback.
|
|
ui = @UI@
|
|
|
|
# ── Auto-unseal (optional) — DEFAULT IS MANUAL UNSEAL ────────────────────────
|
|
# DEPRECATED: the BUILT-IN pkcs11 seal below is removed in OpenBao v2.7.0, and
|
|
# the HSM distribution is discontinued by then. PKCS#11 auto-unseal continues
|
|
# via the external KMS plugin (`plugin "kms" "pkcs11" {}`), so a stack that
|
|
# needs it must move before taking 2.7.x.
|
|
# With no seal stanza OpenBao starts SEALED and needs `bao operator unseal` (x3)
|
|
# after every restart. To auto-unseal against a PKCS#11 HSM/token, uncomment and
|
|
# fill this in, mount the PKCS#11 module + device into the container, and set
|
|
# OPENBAO_HSM_PIN in .env:
|
|
#
|
|
# seal "pkcs11" {
|
|
# lib = "/usr/lib/softhsm/libsofthsm2.so"
|
|
# slot = "0"
|
|
# pin = "env://BAO_HSM_PIN"
|
|
# key_label = "kanrisha-unseal"
|
|
# mechanism = "0x1087" # CKM_AES_GCM
|
|
# }
|