g14wxz/vault-secrets-pattern
Enforces pgsodium Vault for secret storage accessed only via SECURITY DEFINER functions on service_role.
100
100%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
index.mddocs/
Vault Secrets Pattern
Enforces pgsodium Vault for secret storage accessed only via SECURITY DEFINER functions on service_role.
Overview
This tile eliminates hardcoded API keys and credentials by mandating the pgsodium Vault extension as the sole secret-storage mechanism. Secrets are stored encrypted in vault.secrets and accessed exclusively through SECURITY DEFINER functions owned by postgres and granted only to service_role. No other role may read decrypted secret values.
Reference
Core Vault Functions
| Function | Purpose |
|---|---|
vault.create_secret(secret, name) | Insert a new encrypted secret |
vault.update_secret(id, new_secret) | Rotate an existing secret |
vault.decrypted_secrets | View that returns decrypted values (restricted access) |
Accessor Function Template
CREATE OR REPLACE FUNCTION get_secret(secret_name text)
RETURNS text
LANGUAGE sql
SECURITY DEFINER
AS $$
SELECT decrypted_secret
FROM vault.decrypted_secrets
WHERE name = secret_name
LIMIT 1;
$$;
ALTER FUNCTION get_secret(text) OWNER TO postgres;
REVOKE EXECUTE ON FUNCTION get_secret(text) FROM public, anon, authenticated;
GRANT EXECUTE ON FUNCTION get_secret(text) TO service_role;Required Extensions
| Extension | Purpose |
|---|---|
pgsodium | Encryption and Vault support |
Dependencies
- supabase-mcp-verification — MUST pass before any Vault operations execute via MCP.
- service-role-boundary — MUST be installed to enforce role-based access restrictions on accessor functions.
Composition Position
This tile operates after MCP verification confirms connectivity. It provides secret-access primitives that downstream tiles (e.g., Edge Functions calling external APIs) consume. It does not manage the secrets' business logic — only secure storage and retrieval.