Databases

This page explains how database access works with Ironchip PAM. It is for whoever administers the databases and whoever connects with a database client.

How it works

The person connects with their client (psql, mysql or another) and a single-use ticket as the username. The Ironchip PAM broker holds the connection while Ironchip checks the window, the address and the factors, and connects it to the database with the resource’s credential. The person never knows the password.

• PostgreSQL, MySQL and MariaDB. Only with the native client, not from the console.
• Approval on connection: PostgreSQL tells the person that their session is waiting for approval; with MySQL, the client simply waits.
• Connection record: who, when, from where and to which database. The content of the session is not recorded.

Password managed by Ironchip

Choose Managed by Ironchip: nobody types or sees it and enter an administration account (Admin account and Admin password). The secret store signs in with it, sets a password nobody knows on the resource’s account and changes it every day and after every session. Only the secret store keeps the administration account. See Password rotation.

With A stored password, the console shows the CREATE ROLE (PostgreSQL) or CREATE USER (MySQL) statements to prepare the account.

Database credentials for applications

On a database with a managed password, you can create short-lived credential roles: your applications and pipelines request an account with any Vault client, for example a read-only account for one hour, and the account is deleted automatically when it expires.

vault read database/creds/reporting

Steps

1. Register the database as a PostgreSQL or MySQL resource and add it to a target policy.

2. Name that policy in an access.

3. The person requests access, if needed, and connects:

   psql -h <PAM_HOST> -p <PORT> -U ticket-<TICKET>
   mysql -h <PAM_HOST> -P <PORT> -u ticket-<TICKET>