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 today, with more database providers planned.

Creating a Leased Credential

From the secrets page, click + New Secret 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 by default).
• Database: the database name.
• Admin user and Admin password: a role SikkerKey uses to create and remove logins. It needs permission to manage roles (in PostgreSQL, CREATEROLE or SUPERUSER).

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: give each login an expiry your database enforces on its own (a VALID UNTIL in PostgreSQL).
• 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.

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.