Teleport Database Access: Short-Lived Certificates for PostgreSQL and MySQL

The Problem: Long-Lived Database Passwords

Many teams store database credentials in secrets managers or application config files and rotate them infrequently. A stolen PostgreSQL or MySQL password gives an attacker direct access until someone notices and changes it. Because the credential is static, audit logs show only that a connection happened, not which individual used it or what they intended to do.

How Teleport Replaces Static Database Credentials

Teleport issues short-lived certificates instead of distributing long-lived database passwords. A certificate authority (CA) signs a certificate that contains the user's identity, the target database, and a time-to-live (TTL), typically measured in hours. The Teleport Database Agent sits between the client and the target database and enforces the policy embedded in the certificate.

Role-based access control (RBAC) determines which databases a role can reach and what operations are allowed. Access can be federated through an OIDC or SAML identity provider, so a user's corporate group membership controls their database permissions rather than a shared local account.

What the components do

• Teleport Proxy: The entry point where users authenticate and receive certificates.
• Teleport Database Agent: A process deployed near target databases that proxies connections and enforces certificate-based access.
• Short-lived certificate: A signed, time-bound credential that expires automatically, reducing the value of stolen material.

Worked Example: Read-Only PostgreSQL Access

This example assumes a Teleport cluster is already running and the tsh client is installed on your workstation. Placeholders in angle brackets should be replaced with your own values. Exact command flags depend on your Teleport version; consult the documentation for your installed version before automating role creation.

Step 1: Create a read-only database role

Run this on the Teleport administrative node. You need cluster administrator permissions to create or modify roles.

# Example only; verify flags against your Teleport version
tctl create role db-readonly \\
    --allow-uri-db "postgres://:5432/*" \\
    --ttl 2h \\
    --require-mfa

This role allows read-only connections to the specified PostgreSQL host for two hours and requires multi-factor authentication at login.

Step 2: Log in and discover databases

Run on your client machine as a regular Teleport user.

tsh login --proxy=
tsh db list

Expected check: tsh status should show a certificate with a TTL of roughly two hours and the db-readonly role assigned.

Step 3: Connect to the database

tsh db login 
psql "host= user= dbname="

Risk: If you type passwords or API tokens into the database session, they may be captured in session recordings. Avoid entering secrets through recorded connections.

Step 4: Verify audit logging

Run on the Teleport administrative node or query your configured audit backend. Exact query syntax varies by backend and Teleport version.

# Example; syntax depends on your audit backend and version
tctl get audit --since=1h --event=session.start

Expected check: The audit stream should include a session start event for your user and the target database. If no events appear, check that the audit backend is configured and reachable.

Limitations and Trade-Offs

• Certificate authority risk: Compromise of the Teleport CA allows impersonation of any user or host. Back up, rotate, and tightly restrict access to CA keys.
• Edition differences: Some database access features and session-recording capabilities are available only in Teleport Enterprise. Confirm your edition before building automation around a specific feature.
• Session recording privacy: Recordings can capture passwords, tokens, or personally identifiable information typed into terminals. Apply redaction policies or avoid running secrets through recorded sessions.
• Network dependence: Teleport requires connectivity between the Proxy, agents, and targets; it does not replace firewalls or routing.

Practical Closing Steps

1. Deploy the Teleport Database Agent near your PostgreSQL or MySQL targets and confirm network reachability to the Proxy.
2. Create least-privilege roles using tctl get roles or the Teleport Web UI to review allow and deny rules.
3. Require users to run tsh login before database access and verify the certificate TTL with tsh status.
4. Confirm session events appear in your audit backend after a test connection.
5. If you created a test role and no longer need it, remove it with tctl delete role db-readonly to avoid leaving unused access paths.

Short-lived certificates shrink the window for credential theft and make every database session attributable to an individual identity. The trade-off is disciplined CA management and awareness of which features require an Enterprise license. Start with one read-only database role, verify the audit trail, and expand from there.