# Daedro Secrets

**Current requirements:** [Public release specification](public-release-spec.md)
and [security architecture](design/secret-auth-architecture.md). Daedro Secret
is an independent module behind the shared Hub. Human secret actions require
Google Authenticator confirmation bound to the specific operation. The current
pilot does not implement customer secret management or public tenant isolation.

**Verified pilot state (November 5):** the private cloud Hub uses separate
Linux identities for the web service, Daedro Secret and the S3 worker. Encrypted
state is stored in the independent private OpenBao instance. Fresh TOTP checks
gate customer secret operations. A one-use, scope- and request-bound ticket lets
the worker read its credential after grant revalidation. The two-user server
acceptance exercised real S3 object metadata, foreign-profile denials and
revocation. See the [S3 guide](shared-s3.md). Public release still requires
factor recovery, independent audit, disaster recovery and additional review.

The earlier owner/password pilot could run a synthetic fixture but could not
import new provider keys because its recovery RSA passphrase was unavailable.
The new pilot has separate storage and a recovery bundle encrypted using a
Mac Keychain wrapping key. Operator access to that Mac remains necessary for
this pilot's unseal procedure. The current exact-path OpenBao credential expires
on November 12, 2026 at 03:43:33 UTC (10:43:33 Asia/Ho_Chi_Minh), just before
the approved VM shutdown. Rotation and recovery remain operator responsibilities.

## Planned management experience

Secrets belongs to a workspace. The flow is **Add secret → Allow selected MCPs →
Save**. Values remain hidden after saving. Lists show name, version, allowed
workloads and rotation date. Sharing an MCP never shares its credentials.
Reveal, export, grant changes and rotation require fresh MFA. Machine execution
uses short-lived workload credentials, not interactive MFA challenges.

## Trust boundaries

Run OpenBao on a private dedicated host, separate from uploaded MCP execution.
Use production TLS, encrypted storage, encrypted snapshots and separately held
unseal material. Do not use development mode or persist a root token in the hub.
A single node is a pilot with downtime risk, not high availability.

The host broker authenticates each deployment and resolves workspace ownership
and explicit secret grants server-side. Never accept a client-provided workspace
as authorization. It issues a workload-specific short-lived OpenBao token whose
ACL permits only the required data paths. The pilot issues a fresh, one-use
SecretID and accepts only service tokens with a maximum five-minute TTL. It
revokes the reader token before starting the MCP; revocation failure denies the run.
AppRole policies and human enrollment remain administrator provisioning tasks.

The Go reader pins exact versions and independently checks its grant allowlist.
It rejects HTTP, redirects, invalid TLS, oversized responses, missing versions and
deleted secrets. Errors omit upstream bodies. It does not implement policy
issuance or prove that the supplied OpenBao token is narrowly scoped.

Keep metadata endpoints, OpenBao and the Docker socket unreachable from worker
containers. Inject only needed values through read-only memory-backed files;
legacy environment injection must be documented as visible to host administrators.
No secrets in Git, YAML, image layers, arguments, logs or ordinary backup files.
A compromised privileged host can access runtime plaintext; encryption and MFA
cannot remove this risk. A compromised MCP can exfiltrate its own granted secret;
use restricted provider credentials and outbound network allowlists.

## Human authentication and recovery

Use an OIDC identity provider with enforced WebAuthn/passkeys and a documented,
verified authentication-context contract. Google login alone is insufficient.
Verify issuer, audience, signature, nonce, authentication context and freshness;
reject missing MFA evidence. Step-up must be bound to the specific action and
session, expire within five minutes and prevent replay. Protect mutations with
CSRF checks. TOTP fallback and recovery require explicit reviewed policy and
rate limits; recovery must not silently bypass MFA.

Keep offline recovery material with separate custodians. Establish and test
sealed restart, restore, lost-device recovery and emergency revocation before
production. Audit actor, workspace, workload, action, version and result without
values. Export audit records off-host; unavailable required auditing must prevent
sensitive actions.

## Delivery gates

1. Pin and verify an OpenBao release; configure private TLS and production storage.
2. Implement workload token issuance, exact-path ACLs and revoke-on-stop behavior.
3. Integrate enforced human MFA and action-bound step-up, including recovery.
4. Connect authorized metadata/write APIs and the Secrets UI; use KV v2 CAS writes.
5. Implement memory-only injection, network restrictions and off-host auditing.
6. Test cross-tenant denial, expired/revoked credentials, redirects, sealed outages,
   malicious workers, MFA replay, snapshot restore and rotation during execution.
7. Complete independent security review before accepting real tenant secrets.

Rotation creates a new version and explicitly updates grants. Revoke the old key
at the external provider: revoking an OpenBao token does not revoke an API key
already read by a process. KV data is static and does not itself expire with the
reader token. No plaintext fallback is allowed when OpenBao is unavailable.

## References

- [OpenBao KV v2 and ACLs](https://openbao.org/docs/secrets/kv/kv-v2/)
- [OpenBao HTTP API](https://openbao.org/api-docs/)