Abstract Secrets Management

[seletz]

Situation

Currently secrets are fetched by calling the op binary, hard coded. There are many other ways credentials are managed. There's no reason this can't be generic.

Objective

Abstract away the concrete tool used to fetch credentials. Users configure any tool that reads a template from stdin and writes resolved key=value pairs to stdout.

Design

Protocol

1. The CLI pipes the configured template to the command's stdin
2. The command writes key=value lines to stdout (order does not matter)
3. The CLI maps known keys to config fields; unknown keys are ignored

Configuration

The [secrets] section replaces [op_secrets]:

[secrets]
cmd = "op inject"
template = """
username=op://vault/item/username
api-key=op://vault/item/api_key
"""

Known field names

• url, database, username
• api-key (maps to cfg.Password)
• password (maps to cfg.WebPassword)
• totp_secret

Error handling

If [secrets] is configured and the command is not found or fails, fail loudly. No silent fallback.

Priority order (unchanged)

Config file fields → [secrets] → environment variables (highest)

Migration

1. Walk the config hierarchy (project dir upward → global config) looking for [op_secrets]
2. Stop at the first file that contains [op_secrets] — migrate that one
3. If none found, fall back to the root config (~/.config/odoo-work-cli/config.toml)
4. The CLI MUST: inform the user of exact steps, ask permission, create a backup
5. Convert [op_secrets] → [secrets] with cmd = "op inject" and build template from old fields
6. Only one file per invocation. Config hierarchy MUST NOT break.