Leased Secrets

Leased secrets create short-lived database or Redis credentials when an authorized machine reads them. Each machine receives its own provider account, password, and expiry, while applications continue to connect with the provider’s normal client libraries.

#How leased secrets work

The provider username is stable for one machine and leased secret, begins with sk_l_, and remains separate from the usernames issued to other machines. Re-minting replaces its password so the previous credential stops authenticating.

#Supported providers

Administrative account requirements

• PostgreSQL and PostgreSQL (Supabase): CREATEROLE or SUPERUSER, plus permission to apply the configured grants.

• MySQL and MariaDB: CREATE USER, ALL PRIVILEGES, or equivalent operator access, plus permission to apply the configured grants.

• Redis: an ACL account with the administrative command permissions needed to list, create, update, and delete ACL users.

For PostgreSQL (Supabase), enter the 16–32 character lowercase project reference from the Supabase pooler hostname. SikkerKey appends it when connecting through Supavisor while keeping the database role name unchanged.

#Prepare the provider connection

Use a publicly routable hostname that resolves to the provider and accepts connections from SikkerKey. The connection check rejects loopback, private, link-local, and metadata addresses. Configure the provider firewall or network allowlist so SikkerKey can reach the selected port.

#Create a leased secret

New leased secrets default to 32-character passwords using uppercase letters, lowercase letters, and numbers. The default lease lasts one hour, renews on reads made within the final 15 minutes, revokes when its machine is disabled, and uses PostgreSQL database-enforced expiry when available.

#Configure issued access

Grants define what each issued provider account can do. Leave the grants field empty to issue a login-only SQL account or a Redis account limited to connection commands.

Use the grant builder

Select Build template to start with Read-only, Read / write, or a broader provider-specific preset. You can then adjust individual privileges and scope before inserting the result.

• PostgreSQL can scope grants to a schema, include sequence access, and apply matching default privileges to future tables and sequences.

• MySQL and MariaDB scope generated grants to the configured database.

• Redis can scope commands to a key pattern and optionally a Pub/Sub channel pattern.

Write a SQL grant template

For PostgreSQL, MySQL, or MariaDB, use {{name}} wherever the issued account should appear. SikkerKey replaces it with the safely quoted provider username during each mint.

GRANT SELECT ON ALL TABLES IN SCHEMA public TO {{name}};

Write Redis ACL rules

For Redis, enter the key patterns, channel patterns, and command categories that should follow the issued username and password.

~app:* +@read +@write

#Configure the lease policy

MySQL, MariaDB, and Redis enforce expiry through account removal. If the provider is temporarily unreachable, SikkerKey retries revocation with increasing intervals until the account is removed.

#Grant a machine access

A read passes through machine authentication, project membership, the explicit secret grant, project lock state, and any attached access policy before SikkerKey contacts the provider.

#Understand reads, renewal, and expiry

#Manage an existing leased secret

Open the row menu and select Configure. The leased-secret configuration has four tabs.

Status

• Active allows authorized machine reads to mint or return leased credentials.

• Disable minting stops new reads. Provider accounts already issued remain active until their lease expires or another revocation event removes them.

• Enable minting resumes authorized reads.

Policy

Change the lifetime, renewal window, hard maximum, database-native expiry, machine-disable revocation, or mint-on-every-read behavior, then select Save policy. Existing provider credentials retain their current account and expiry until subsequent reads, renewal, expiry, or revocation applies the new behavior.

Grants

Edit the access template directly or use Build template, then select Save grants. The saved template is used when SikkerKey next mints the provider credential.

Connection

Update the host, port, database, connection security, project reference, or administrative credentials. Re-enter the administrative username and password, select Test connection, and then select Save connection.

#Delete a leased secret

Deleting a leased secret stops further reads immediately, queues every issued provider account for removal, removes its provider connection and lease configuration, and moves the retained secret record to Trash for 30 days. The same account-removal workflow runs when its project or vault is deleted.

SikkerKey retries queued account removal when the provider is temporarily unavailable. Restoring the retained Trash record recovers its name, secret ID, and history in the original project. Create a new leased secret to establish a new provider connection, policy, grants, and credential lifecycle.

#Troubleshoot leased secrets