Leased Credentials

A leased credential is a short-lived database login that SikkerKey creates on demand. You connect a database once and choose how long a login should live. When one of your machines reads the secret, SikkerKey provisions a fresh login in that database and returns the full connection to that machine. When the lease ends, the login is removed.

Each machine gets its own login, and it lives only as long as the workload needs it.

How It Works

1. You connect a database from the dashboard and give SikkerKey a privileged role it can use to create and remove logins.
2. You set the lease policy: how long a credential lives, whether it renews under use, and when it is revoked.
3. A machine reads the secret through the SDK or CLI, exactly as it reads any other secret.
4. SikkerKey mints a login for that machine and returns the connection fields: host, port, database, username, and password.
5. The login is extended while the machine keeps reading (when you allow renewal) and removed when the lease ends or the machine is disabled.

Logins are created directly in your database, so your application connects the way it always has.

Supported Providers

Leased credentials are available for PostgreSQL, MySQL, and MariaDB today, with more database providers planned.

Creating a Leased Credential

From your project's Secrets page, click the + button in the top-right corner of the table and select Leased Secret. The wizard has three steps.

1. Connection

Enter the database SikkerKey will mint logins in:

• Host and Port: where the database is reachable (5432 for PostgreSQL, 3306 for MySQL and MariaDB).
• Database: the database name.
• Admin user and Admin password: an account SikkerKey uses to create and remove logins. It needs privilege to manage logins (in PostgreSQL, CREATEROLE or SUPERUSER; in MySQL or MariaDB, CREATE USER).

Click Test connection to confirm the details are valid and the role can create logins before you continue. The connection material is encrypted at rest and is used only to mint and remove credentials.

2. Credential Shape

Choose what each minted login looks like:

• Password length and charset (symbols, alphanumeric, numbers, or uuid): how the generated password is formed.
• Grants (optional SQL): runs on each new login, so you can scope it to exactly the access your app needs. Use {{name}} where the role name goes. Leave it blank for a login with no extra privileges.

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

Because a grants template runs SQL against your database, editing it is reserved for the vault owner.

3. Lease Policy

The lease policy decides how minted credentials behave over time:

• Credential lifetime: how long a login stays valid (minimum one minute).
• Renew on read: extend the login while a machine keeps using it. The renew window sets how close to expiry a read triggers renewal.
• Hard maximum: force a fresh login after a ceiling, even under continuous use.
• Database-native expiry (PostgreSQL only): give each login a VALID UNTIL the database enforces itself. MySQL and MariaDB have no equivalent, so there the lease is enforced by SikkerKey removing the login on expiry.
• Revoke when machine disabled: remove a machine's login the moment you disable that machine.
• Mint fresh on every read: issue a brand-new login on each fetch instead of reusing one within its lease.

Reading a Leased Credential

A machine reads a leased credential the same way it reads a structured secret: the SDK returns the connection fields.

# Python
db = sk.get_fields("sk_db_prod")
conn = connect(
    host=db["host"], port=db["port"], dbname=db["database"],
    user=db["username"], password=db["password"],
)

// Kotlin
val db = sk.getFields("sk_db_prod")

// Go
db, _ := sk.GetFields("sk_db_prod")

# CLI (prints the connection fields as JSON)
sikkerkey get sk_db_prod

The SDK signs the request with the machine's Ed25519 identity, and SikkerKey returns the login that belongs to that machine. The first read from a machine mints a login; reads within the lease return the same login and renew it when your policy allows; a read after expiry issues a new one. With Mint fresh on every read enabled, each read returns a new password.

SDKs are available for Python, Node.js, Go, .NET, JVM, and PHP, and the same read works from the CLI.

Managing a Leased Credential

Open a leased secret's Configure Secret interface with the Configure button () to change how it behaves after creation. It has three parts:

• Status: whether SikkerKey is minting for this secret, and the connected database. Disable minting stops it from issuing or serving logins; reads fail until you enable it again, and logins already in your database remain until their lease expires. Enable minting turns it back on.
• Lease policy: adjust the credential lifetime, renewal, hard maximum, revoke-on-disable, and mint-fresh-on-every-read. Saved changes apply to the next mint; leases already in flight keep their current bounds until they renew or re-mint.
• Update connection: change the host, port, database, or the admin credentials SikkerKey uses to mint logins, and Test connection to check them first. Admin credentials are never shown, so re-enter them to verify or rotate them.

Deleting a Leased Credential

Deleting a leased credential removes its minted logins from your database, then moves the secret to trash. The same cleanup runs when you delete the credential's project or vault, so logins never outlive the secret that created them.

Mint, renewal, and revocation are written to the audit log, so you can see which machine held which login and for how long.