[➕ Feature]: Configurable Vault secret path prefix

[rottingfikaloid]

Is your feature request related to a problem? Please describe.
Currently, Keep writes secrets directly to the root of the KV secrets engine
(e.g., secret/data/keep_ssh_xxx).
This is not a best practice for HashiCorp Vault.

Describe the solution you'd like
Add an environment variable HASHICORP_VAULT_SECRET_PATH_PREFIX that allows
configuring a custom path prefix for secrets.

Example:

• Current behavior: secret/data/keep_ssh_df9fc135...
• Desired behavior: secret/data/keep/keep_ssh_df9fc135...

Describe alternatives you've considered

• Using a dedicated KV mount point for Keep (requires code changes).
• Vault Policy with wildcards (works, but secrets still clutter the root path).

Additional context
HashiCorp Vault best practices recommend organizing secrets in a hierarchical
structure for better audit, policy management, and multi-tenancy.

[AaronProbha18]

Hi! I'd like to work on this issue if it's available.

My proposed approach is:

• Add support for a new environment variable, HASHICORP_VAULT_SECRET_PATH_PREFIX, in keep/secretmanager/vaultsecretmanager.py.

• Construct the effective Vault path based on whether the prefix is configured:

  • Current behavior (default): keep_ssh_xxx
  • With HASHICORP_VAULT_SECRET_PATH_PREFIX=keep: keep/keep_ssh_xxx

• Apply the same path construction logic consistently across:

  • write_secret
  • read_secret
  • delete_secret

• Preserve backward compatibility when the environment variable is not set.

• Update tests in tests/test_secretmanager.py to verify both prefixed and non-prefixed path behavior and ensure the correct Vault path is used for write, read, and delete operations.

Does this approach sound good? If so, may I take up this issue and submit a PR?
@shahargl

[rottingfikaloid]

Hi!

@AaronProbha18 , thank you for your willingness to help!

The environment variable issue is only half the story.
While examining the source code, I discovered that Keep uses Vault as a simple secrets store.
That is, we grant it full access to the Vault space, and Keep manages secrets there.
However, in the Keep UI, secrets are not hidden in any way; they are displayed as is, not as some attribute (secret name) that Keep uses to look up the value (secret value) in Vault .
Yes, there's a spoiler, but this is only to protect against prying eyes.

Example:

How it should be
In Vault, we have the entry:
kibana_token: Q4Da6vdIQXhewiUy3ZFgIBrS
In Keep-backend, we activate Vault as the primary secrets store.
In the Keep-frontend field, we simply enter kibana_token in the secret_key field, and Keep-backend will look for the kibana_token value in the Vault.
This scheme is extremely secure.

As is
In the Keep-frontend field, we enter the secret Q4Da6vdIQXhewiUy3ZFgIBrS.
The only protection for this secret in Keep-frontend is a spoiler.
And Keep-backend generates a unique name for this secret and stores it in the Vault.

That's why I abandoned Vault, as it didn't really make sense.
I went back to storing secrets in the database, but encrypted them using PostgreSQL.

If you're interested, here's what I did (from my docs in the Joplin):

psql -U **PostgreSQL** -d keep_db

-- Enable the extension
CREATE EXTENSION IF NOT EXISTS pgcrypto;
-- Set the key as a database parameter (not visible in the VIEW definition)
ALTER DATABASE `keep_db` SET app.encryption_key = 'vIxcaflu9KXUGzX3OAU1g8nvIYYolL2wcuRiZ3V78aESdfa9';

-- Drop old tables
DROP TABLE IF EXISTS secret;

-- The secret_encrypted table stores ONLY encrypted data
CREATE TABLE secret_encrypted (
    key TEXT PRIMARY KEY,
    value TEXT NOT NULL,
    last_updated TIMESTAMPTZ DEFAULT NOW()
);

-- VIEW for transparent database-level encryption without changing the Keep code
CREATE OR REPLACE VIEW secret AS 
SELECT 
    key,
    convert_from(
        pgp_sym_decrypt(dearmor(value)::bytea, current_setting('app.encryption_key'))::bytea, 
        'UTF8'
    ) AS value,
    last_updated
FROM secret_encrypted;

-- Grant the application read permissions on the VIEW and table
GRANT SELECT, INSERT, UPDATE, DELETE ON secret TO keep_user;
GRANT SELECT, INSERT, UPDATE, DELETE ON secret_encrypted TO keep_user;

-- Create a function that automatically encrypts values ​​before writing them to the secret_encrypted table
CREATE OR REPLACE FUNCTION encrypt_secret_value()
RETURNS TRIGGER AS $$
BEGIN
    NEW.value := armor(
        pgp_sym_encrypt(NEW.value, current_setting('app.encryption_key'))
    );
    RETURN NEW;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

-- Create a trigger that fires every time someone attempts to write or update data in the secret_encrypted table
DROP TRIGGER IF EXISTS trg_encrypt_secret ON secret_encrypted;
CREATE TRIGGER trg_encrypt_secret
BEFORE INSERT OR UPDATE ON secret_encrypted
FOR EACH ROW EXECUTE FUNCTION encrypt_secret_value();

-- Create functions and triggers on VIEW secret that intercept DELETE/UPDATE/INSERT operations and redirect them to the physical table secret_encrypted, where the trg_encrypt_secret trigger will automatically encrypt them:
-- DELETE
CREATE OR REPLACE FUNCTION delete_from_secret_encrypted()
RETURNS TRIGGER AS $$
BEGIN
    DELETE FROM secret_encrypted WHERE key = OLD.key;
    RETURN OLD;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

CREATE TRIGGER trg_delete_secret
INSTEAD OF DELETE ON secret
FOR EACH ROW EXECUTE FUNCTION delete_from_secret_encrypted();

-- UPDATE
CREATE OR REPLACE FUNCTION update_in_secret_encrypted()
RETURNS TRIGGER AS $$
BEGIN
    UPDATE secret_encrypted 
    SET value = NEW.value, last_updated = COALESCE(NEW.last_updated, NOW())
    WHERE key = OLD.key;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

CREATE TRIGGER trg_update_secret
INSTEAD OF UPDATE ON secret
FOR EACH ROW EXECUTE FUNCTION update_in_secret_encrypted();

--INSERT
CREATE OR REPLACE FUNCTION insert_into_secret_encrypted()
RETURNS TRIGGER AS $$
BEGIN
    INSERT INTO secret_encrypted (key, value, last_updated)
    VALUES (NEW.key, NEW.value, COALESCE(NEW.last_updated, NOW()))
    ON CONFLICT (key) DO UPDATE SET 
        value = EXCLUDED.value, 
        last_updated = EXCLUDED.last_updated;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

CREATE TRIGGER trg_insert_secret
INSTEAD OF INSERT ON secret
FOR EACH ROW EXECUTE FUNCTION insert_into_secret_encrypted();

Functions:

• encrypt_secret_value()
• delete_from_secret_encrypted()
• update_in_secret_encrypted()
• insert_into_secret_encrypted()

and triggers:

• trg_encrypt_secret
• trg_delete_secret
• trg_update_secret
• trg_insert_secret

physically reside only in the keep_db database.
In PostgreSQL, functions, triggers, tables, and views are database-specific objects.
They are not visible or accessible in other databases on the same server (for example, if you have app_db and keep_db).
When we connect to keep_db as the PostgreSQL superuser and create the entities listed above, then:

• Functions are created in the pg_proc system catalog of the keep_db database.
• Triggers are bound to the secret_encrypted table in keep_db.
• The app.encryption_key parameter set via ALTER DATABASE keep_user SET ... also applies only to sessions of this user in the context of this database (or globally for a role, but it is read within the function already connected to keep_db).

1. Only PGP blobs are stored on the server disk, in WAL logs, and in backups (pg_dump).
2. If attackers steal the disk with the database or a database backup, this will not lead to a compromise of secrets.
3. All cryptographic objects (functions, triggers, VIEW) and the key parameter (app.encryption_key) are tightly bound to the system catalogs of the specific keep_db database.
4. A compromised user or vulnerability in another database on the same PostgreSQL server (e.g., app_db) will prevent an attacker from accessing Keep secrets.
5. Encryption is enforced by the database engine via triggers. Keep physically cannot write secrets in plaintext. Even if a vulnerability or bug appears in Keep's code, the database engine will intercept the operation and encrypt the data before it is actually written to disk.
6. The database application user (keep_user) does not have permission to perform cryptographic functions and does not store the encryption key in the application's configuration files. The key is passed only within a protected DBMS session parameter, and the encryption function itself is executed with PostgreSQL privileges (thanks to SECURITY DEFINER), but the encryption key is read from the session of the keep_user application user via current_setting().
7. The encryption key is not included in the application logs, is not visible in the container environment variables, and cannot be extracted via SQL injection on behalf of the application user.

[AaronProbha18]

@rottingfikaloid, thanks for the detailed reply - this is a much cleaner model than what we were doing with Vault, and I get why you dropped it. The frontend "secret_key vs literal secret value" issue you found is a real design flaw (loved the term "spoiler").

The trigger-based transparent encryption is a nice pattern too, keeping secret_encrypted as the only physical table. Since app.encryption_key is set at the database level and we are using sqlmodel as the orm across keep which ensure that queries are parameterised and not simple concatenated strings - so keep_user never gets direct access to the secrets even in the app layer which is a great approach.

I think we can close this enhancement then yeah?

[rottingfikaloid]

Hi!
@AaronProbha18

I think we can close this enhancement, then yeah?

No problem, let's close it until better times!
Obviously, managing secrets from Vault would be much easier, especially using its API in CI/CD, but the Keep API would work too.

It's more a question of documentation.
I'd write detailed instructions in MD and ask you to post them in your Github docs, for example, here https://github.com/keephq/keep/blob/main/docs/deployment/secret-store.mdx.
I admit that some organizations have strict requirements for secret storage, but storing secrets in the root of a shared Vault would be unacceptable.
So my method might save time.
Plus, we need to build a community.