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.

• Microsoft SQL Server: an account with permission to create and drop server logins, terminate their sessions, and create and drop the database user — ALTER ANY LOGIN, ALTER ANY CONNECTION, and ALTER ANY USER, or the sysadmin server role, plus permission to apply the configured grants.

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.

For Microsoft SQL Server, SikkerKey creates a server-level login and a mapped user in that database, then applies the configured grants to the database user. On revocation, it removes the database user before the server login and retries if SQL Server is temporarily unreachable.

#Prepare the provider connection

SikkerKey can reach the provider two ways. Use a publicly routable hostname when the provider accepts connections from the internet, or route the connection over a tunnel when it does not.

For a public connection, use a 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.

Reach a provider through a tunnel

A tunnel lets SikkerKey issue credentials for a database that accepts no connections from the internet. A connector runs on a host inside your network and holds a private outbound connection, and SikkerKey reaches the database through the target you declare on it.

When a tunnel is available, selecting the host field offers your tunnels. Choosing one turns the port field into a target picker, and selecting a target fills the host and port from the target’s own definition. The address is resolved on the machine running the connector, so private addresses and internal DNS names are expected here.

Minting, renewal, and revocation all travel over the tunnel. Your applications are unaffected and continue to connect to the database directly on your own network using the returned connection fields.

#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.

• Microsoft SQL Server scopes object privileges to a schema (dbo by default), where they cover current and future objects. CREATE TABLE, CREATE VIEW, and CREATE PROCEDURE privileges are database-scoped.

Write a SQL grant template

For PostgreSQL, MySQL, or MariaDB, use The same placeholder is used for Microsoft SQL Server and is rendered as a safely bracket-quoted database user.{{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}};

For Microsoft SQL Server, schema grants cover both existing and future objects in that schema. The grant builder uses dbo by default; database-scoped CREATE privileges are emitted as separate statements.

GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::[dbo] 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. Microsoft SQL Server follows the same removal-and-retry model because SQL Server logins do not have a timestamp-based lease expiry.

#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