Daedro Secrets
Current requirements: Public release specification and security architecture. 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. 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
- Pin and verify an OpenBao release; configure private TLS and production storage.
- Implement workload token issuance, exact-path ACLs and revoke-on-stop behavior.
- Integrate enforced human MFA and action-bound step-up, including recovery.
- Connect authorized metadata/write APIs and the Secrets UI; use KV v2 CAS writes.
- Implement memory-only injection, network restrictions and off-host auditing.
- Test cross-tenant denial, expired/revoked credentials, redirects, sealed outages, malicious workers, MFA replay, snapshot restore and rotation during execution.
- 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.