Enterprise Edge

Local Vault

Local Vault to outbound-only customer edge component dla connector secret storage, source attestation signing, offline spooling, event relay, opcjonalnego customer-side witness operation oraz, w Local Vault 2.x, provenance mode Attesto 3, w którym capsules pozostają na hoście edge, a do platformy docierają tylko commitments. To nie jest HashiCorp Vault.

Responsibilities

Encrypt connector credentials lokalnie.
Podpisywać source attestations przed relay.
Spool events podczas network outages.
Replay spooled events w kolejności z idempotency.
Działać jako customer-side witness, gdy tenant policy to włącza.

Lokalna provenance obrazów używa izolowanego providera i szyfrowanego keyed registry opisanych w przewodniku AttestoMark Image.

Instalacja i uruchomienie

Zainstaluj Local Vault na kontrolowanym przez klienta hoście edge. Współrzędne runtime mogą pochodzić z flag lub zmiennych środowiskowych, ale signing keys, spool encryption keys i connector credentials muszą pochodzić z lokalnego deployment secret managera. Nie umieszczaj ich w shell history, konfiguracji frontendu ani docs Attesto.

Zalecana instalacja to podpisany kanał kontenerowy: installer jednym poleceniem pobiera obraz vaulta przypięty digestem, tworzy katalogi state i config oraz instaluje wrapper attesto-local-vault, dzięki któremu każde polecenie CLI działa transparentnie w kontenerze. Wymagany jest Docker (Docker Desktop na macOS i Windows).

# Linux / macOS
curl -fsSL https://get.attesto.eu/local-vault/install.sh | sh

# Windows (PowerShell)
irm https://get.attesto.eu/local-vault/install.ps1 | iex

# Image pinned by digest (override: ATTESTO_LOCAL_VAULT_IMAGE):
# git.attesto.eu/attesto/local-vault@sha256:5799e7f0669c9b42a55a338f4233cfa5afb5aa6a2627c2c50f7545a41bff1551

Na macOS i Windows vault i jego linuksowa provider sandbox działają w linuksowej VM Docker Desktop; gwarancje izolacji obowiązują wewnątrz tej VM. Natywny proces macOS lub Windows by ich nie niósł — właśnie dlatego installery są wrapperami kontenera. Odinstalowanie: usuń wrapper, usuń obraz przez docker rmi i, tylko jeśli dowody nie są już potrzebne, usuń katalog state — install.sh --help wypisuje dokładne polecenia.

Na macOS i Linuksie ten sam wrapper kontenerowy instaluje się też przez Homebrew. Hashe formuły są kopiowane dosłownie z podpisanego przez cosign manifestu kanału, a Homebrew wymusza je przy każdej instalacji; caveats powtarzają wymaganie Dockera i powyższą notę o uczciwości:

brew tap attesto/attesto https://git.attesto.eu/attesto/homebrew-attesto.git
brew trust attesto/attesto
brew install attesto-local-vault

Na hostach Debian/Ubuntu i Fedora/RHEL natywne pakiety instalują ten sam wrapper jako /usr/bin/attesto-local-vault, uruchamiający ten sam obraz przypięty przez digest. Deb ma twardą zależność od silnika zgodnego z Dockerem (docker-ce | docker.io | podman-docker); rpm nie potrafi wyrazić tej alternatywy między repozytoriami, więc jedynie rekomenduje docker — silnik pozostaje wymagany w runtime. Zweryfikuj podpisany manifest, sprawdź hash pakietu, a następnie zainstaluj:

curl -fsSLO https://get.attesto.eu/local-vault/2.0.1/SHA256SUMS
curl -fsSLO https://get.attesto.eu/local-vault/2.0.1/SHA256SUMS.sig
cosign verify-blob --key https://get.attesto.eu/cosign.pub --insecure-ignore-tlog --signature SHA256SUMS.sig SHA256SUMS

# Debian / Ubuntu (run the install as root)
curl -fsSLO https://get.attesto.eu/local-vault/2.0.1/attesto-local-vault_2.0.1-1_all.deb
sha256sum -c --ignore-missing SHA256SUMS
apt install ./attesto-local-vault_2.0.1-1_all.deb

# Fedora / RHEL (run the install as root)
curl -fsSLO https://get.attesto.eu/local-vault/2.0.1/attesto-local-vault-2.0.1-1.noarch.rpm
sha256sum -c --ignore-missing SHA256SUMS
dnf install ./attesto-local-vault-2.0.1-1.noarch.rpm

Kanał wheel dla Pythona pozostaje dostępny dla hostów uruchamiających vault natywnie na Linuksie:

pipx install attesto-local-vault

export ATTESTO_LOCAL_VAULT_SPOOL_DB=/var/lib/attesto/local-vault.sqlite3
export ATTESTO_LOCAL_VAULT_INSTALLATION_ID="$ATTESTO_LOCAL_VAULT_INSTALLATION_ID"
export ATTESTO_LOCAL_VAULT_RELAY_URL="https://verify.attesto.eu/v2/local-vault/installations/$ATTESTO_LOCAL_VAULT_INSTALLATION_ID/events"
export ATTESTO_LOCAL_VAULT_KEY_ID="$ATTESTO_LOCAL_VAULT_KEY_ID"

attesto-local-vault drain-loop

Kontrola zdrowia

Uruchom attesto-local-vault doctor po bootstrapie oraz podczas operator troubleshooting. Doctor sprawdza config, lokalne secrets, uprawnienia secrets.env, encrypted spool readback, reguły HTTPS dla relay URL, osiągalność backendu, server clock skew, nieprawidłowe nagłówki serwera Date oraz dead-letter depth. Failures zwracają non-zero exit code. Warnings pozostawiają spool używalny, ale operator musi je przejrzeć.

attesto-local-vault doctor

Enrollment

Tenant owner albo admin tworzy krótkotrwały enrollment token przez POST /v2/tenant/local-vault/enrollment-tokens. Edge host wymienia ten token w POST /v2/local-vault/enroll i otrzymuje installation metadata oraz credential potrzebny do outbound relay. Enrollment tokens są single-use; Attesto po utworzeniu zapisuje tylko ich hash.

Potwierdzenie dostarczenia

Local Vault oznacza element jako delivered tylko wtedy, gdy Attesto zwróci 2xx JSON receipt z pasującym localVaultAck.envelopeHash, stream binding i canonical event id. Proxy 2xx, malformed body, mismatched receipt albo revoked installation pozostają nieudaną dostawą pod retry lub dead-letter policy.

Outbound relay flow

Customer source tworzy attestation event.
Local Vault podpisuje i zapisuje event w encrypted spool.
Local Vault relay event do POST /v2/local-vault/installations/{installation_id}/events na https://verify.attesto.eu.
Attesto zwraca Proofstream receipt.
Local Vault zapisuje receipt state i przechowuje retry metadata do zakończenia delivery.

{
  "source_ref": "local-source-2026-0001",
  "event_type": "source.attestation",
  "payload_hash": "sha256-hex",
  "local_signature": {
    "alg": "Ed25519",
    "kid": "local-vault-key-epoch",
    "signature": "hex-encoded-signature"
  }
}

Encrypted spool

Spool zachowuje events podczas network outages. Replay jest uporządkowany i idempotent: ta sama source reference i body mogą być retried, ale changed content dla tej samej source reference jest odrzucany.

State	Znaczenie
`queued`	Zapisane lokalnie i oczekujące na relay.
`relaying`	Outbound request jest w toku.
`receipted`	Attesto zwróciło Proofstream receipt.
`conflict`	Source reference została replayed z inną canonical content.

Security model

Inbound internet route nie jest wymagana dla relay mode.
Connector credentials pozostają encrypted na customer edge.
Relay endpoints odrzucają replay conflicts i tampered envelopes.
Revocation fails closed: revoked installation nie może dalej relaying accepted events.

Customer witness mode

Po włączeniu Local Vault może podpisywać monotonic checkpoints dla swoich tenant streams. Policy 2-of-3 może łączyć Attesto-operated, customer-operated i assurance witness statements, aby żaden pojedynczy service nie był traktowany jako jedyna source of history.

W witness mode Local Vault podpisuje checkpoint statements tylko wtedy, gdy rozszerzają last accepted checkpoint dla tenant stream. Conflict tworzy fork visibility po stronie klienta.

Witness checkpoint statements są wysyłane do POST /v2/local-vault/installations/{installation_id}/witness/checkpoints i akceptowane tylko wtedy, gdy installation jest enabled, scoped do tenant i monotonic dla streamu.

Komenda witness

Użyj komendy operatora, aby podpisać monotonic checkpoint statement albo zwrócić fork evidence dla konfliktowego checkpointu. Komenda wypisuje tylko publiczny materiał receipt/fork; nigdy nie wypisuje private signing key.

attesto-local-vault --witness-db /var/lib/attesto/local-vault-witness.sqlite3 \
  witness-checkpoint \
  --tenant-id ten_... \
  --stream-id str_... \
  --checkpoint-id chk_... \
  --checkpoint-seq-no 42 \
  --checkpoint-hash "$CHECKPOINT_HASH" \
  --previous-checkpoint-hash "$PREVIOUS_CHECKPOINT_HASH"

Provenance mode (Attesto 3)

Local Vault 2.x działa w jednym z trzech trybów, przełączanych przez attesto-local-vault mode --set legacy-relay|provenance|shadow. legacy-relay to opisany wyżej przepływ relay. W trybie provenance vault buduje capsule na każdy asset swoim przypiętym Rust edge core, uruchamia włączone providery w provider sandbox (AttestoMark Image, Audio i Video, C2PA) lub jako mierzone daemony (inference gateway niosący AttestoMark Text), ocenia wielosygnałową policy, przechowuje capsule w zaszyfrowanym lokalnym capsule store i przekazuje envelope ATTESTO-PROVENANCE-001 niosący wyłącznie commitments: subject commitment, capsule root, rooty claims, evidence i policy-results, key id instalacji, jej podpisany poziom assurance oraz, na L1/L2, attestation reference. Surowa treść, prompty, nazwy plików i wyjście providerów nigdy nie opuszczają hosta; platforma nie może zwrócić capsule, bo nigdy jej nie przechowuje. shadow uruchamia obie lanes na potrzeby migracji sterowanej przez attesto-local-vault migration status|advance|roll-back|cutover-evidence; z założenia nie ma --force.

attesto-local-vault mode --set provenance
attesto-local-vault provenance self-test
attesto-local-vault provenance relay-loop

Vault przekazuje do POST /v2/local-vault/installations/{installation_id}/provenance-events, ścieżki, którą obiekt instalacji ogłasza jako provenanceEndpointPath; poświadczeniem jest podpis Ed25519 envelope. Platforma odpowiada receiptem Proofstream plus provenanceAck. Stream musi być provenance stream utworzonym przez POST /v2/provenance/streams pod witness policy zadeklarowaną wcześniej przez PUT /v2/tenant/witness/policies/{policy_id}; przewodnik API wymienia każdą trasę.

Poziomy assurance i hardware custody

Poziom	Wymaga	Co weryfikuje platforma
`L0`	Klucz programowy (domyślnie).	Podpis Ed25519.
`L1`	Ten sam klucz Ed25519 przechowywany w tokenie PKCS#11, nieekstrahowalny.	Rekord attestation `pkcs11-key-custody` podpisany tym kluczem.
`L2`	L1 plus quote TPM 2.0 nad pomiarem vaulta: wersja vaulta, suma kontrolna edge core, provider manifests i signing key.	Podpis quote, jego powiązanie z measurement digest oraz attestation key.
`L3`	Nigdy nie podpisywany przez vault.	Wyprowadzany przez weryfikatora z `L2` plus osiągniętego witness quorum na obejmującym checkpoint; anchoring nigdy nie podnosi poziomu.

Algorytm podpisu nie zmienia się między poziomami. Rekord attestation (ATTESTO-VAULT-ATTESTATION-001) rejestruje się pod POST /v2/local-vault/installations/{installation_id}/attestations; platforma go weryfikuje i odrzuca envelope L1/L2, którego nie może potwierdzić. L2 nie oznacza, że hosta nie da się skompromitować: oznacza, że TPM podpisał oświadczenie o tym, co vault zmierzył przy starcie. Providery PKCS#11 i TPM 2.0 są ćwiczone w continuous integration względem SoftHSM2 i swtpm, programowych dublerów tych interfejsów; żadna instalacja produkcyjna nie podpisała jeszcze sprzętem, a instalacja rolloutu first-party podpisuje kluczem programowym na L0.

Key lifecycle i revocation

Unieważnienie instalacji (DELETE /v2/tenant/local-vault/installations/{installation_id}) zapisuje zegar platformy jako chwilę revocation i publikuje ją pod GET /v2/local-vault/installations/{installation_id}/key-status, które jest celowo publiczne, aby weryfikator niebędący użytkownikiem tenanta mógł sprawdzić dowody offline. Revocation jest oceniana względem platform receipt time każdego zdarzenia, nigdy względem deklarowanego przez vault occurred_at, z granicą włączającą; deklaracja sprzed unieważnienia, której receipt nie jest sprzed niego, otrzymuje flagę suspect_backdated. Verifier bundle nad provenance stream niesie key lifecycle z chwili budowy bundle, więc późniejsze unieważnienie nie znajduje się w bundle.

Stan wdrożenia

Provenance lane jest włączona na produkcji. Faza A kontrolowanego rolloutu została wykonana na produkcji 2026-08-23 z tenantem first-party: 15 receipts, 0 trafień privacy canary w bodies HTTP, logach backendu i 92 tabelach bazy danych, stream z checkpointem i witnessem. Rollback oparty na lane, który kieruje nowe zdarzenia z powrotem do legacy lane i niczego nie przepisuje, przećwiczono względem produkcji. Fazy B do D, w tym migracje design partnerów i domyślne przełączenie nowych konfiguracji na provenance, nie rozpoczęły się.

Offline i online modes

Online relay: events są szybko signed, spooled, relayed i receipted.
Temporary offline relay: events pozostają encrypted w local spool do powrotu outbound network.
Witness online: checkpoint statements są weryfikowane i podpisywane zgodnie z policy.
Witness unavailable: quorum może być opóźnione; receipts pozostają niezależne od witness availability.