Provider request: Keeper Secrets Manager (KSM)

[mdeterman]

Summary

Add a provider for Keeper Secrets Manager (KSM) — Keeper's zero-knowledge secrets platform. It's a common choice in enterprises that already standardize on Keeper for password management, and it currently has no path into fnox short of a command lease.

Why it fits fnox well

Keeper ships an official Rust SDK: keeper-secrets-manager-core (docs), so this wouldn't need a CLI shell-out like the Doppler/1Password providers.

More importantly, Keeper Notation maps 1:1 onto fnox's "value is a provider-specific reference" model:

let result = secrets_manager.get_notation("HDQTnxkTcPSOsHNAlbI4aQ/field/login".to_string())?;

Proposed config

[providers]
keeper = { type = "keeper", config_file = "~/.keeper/ksm-config.json" }

[secrets]
DB_PASSWORD = { provider = "keeper", value = "HDQTnxkTcPSOsHNAlbI4aQ/field/password" }
DB_USER     = { provider = "keeper", value = "HDQTnxkTcPSOsHNAlbI4aQ/field/login" }

Auth would follow the existing provider conventions:

• config_file field pointing at a ksm-config.json (FileKeyValueStorage::new_config_storage)
• fallback to FNOX_KEEPER_CONFIG / KSM_CONFIG env var (base64 config blob), matching how doppler falls back to FNOX_DOPPLER_TOKEN / DOPPLER_TOKEN
• optionally a one-time token for first-run bootstrap

Suggested scope for a first version

• Read-only (ProviderCapability::RemoteRead), like the 1Password and Bitwarden providers — no put_secret initially
• get_secret via get_notation
• test_connection via a trivial app-info call
• get_secrets_batch could later use get_secrets(vec![uid, ...]) to collapse records sharing a UID into one API call

Implementation note

The Rust SDK's API appears to be synchronous (get_notation(...)? with no .await in the docs), so the calls would likely need tokio::task::spawn_blocking inside the async Provider methods. Worth confirming against the crate before settling on a shape.

Offer

Happy to submit the PR (crates/fnox-core/providers/keeper.toml + crates/fnox-core/src/providers/keeper.rs + docs/providers/keeper.md) if this is something you'd want in mainline — just wanted to check on the naming (keeper vs keeper-sm, to distinguish from a possible future Keeper vault/password-manager provider) and on whether pulling in the SDK as a dependency is acceptable before writing it.

[jdx]

Implemented in #720.

This adds a read-only keeper-sm provider backed by Keeper's official Rust SDK. Secret values use Keeper notation (for example, RECORD_UID/field/password). It supports a downloaded JSON config file, KSM_CONFIG/FNOX_KEEPER_CONFIG, and one-time-token bootstrap through KSM_TOKEN/FNOX_KEEPER_TOKEN; bootstrap persists the bound client configuration to config_file.

Thanks for the request and the offer to test—feedback on the PR with a real Keeper application would be useful.

AI-assisted — Tool: Codex; model: openai/gpt-5; version: unavailable.