RBAC lets administrators define granular access policies for databases connected to Airlock.

Example policy: database administrators have access to everything, QA and engineers have full access to staging, and engineers can get temporary access to production in emergencies.

Role configuration

The role resource provides the following controls for restricting database access:

kind: role
version: v5
metadata:
  name: developer
spec:
  allow:
    db_labels:
      environment: ["dev", "stage"]
    db_users: ["viewer", "editor"]
    db_names: ["main", "metrics", "postgres"]

Wildcards

You can use * to match any usernames or database names:

kind: role
version: v5
metadata:
  name: prod-reader
spec:
  allow:
    db_labels:
      environment: ["prod"]
    db_users: ["*"]
    db_names: ["*"]
  deny:
    db_users: ["postgres"]
    db_names: ["postgres"]

Deny rules take priority. Any attempt to connect with the postgres account or to the postgres database will be rejected.

Database names

The behavior of the db_names field depends on the database engine.

PostgreSQL supports multiple logical databases. On connection, db_names is checked against the target database name.

MySQL — the terms “database” and “schema” are synonymous; permissions are determined by grants on the account. The db_names field is not checked when connecting to MySQL.

Template variables

db_* fields support template variables.

{{external.xyz}} is replaced with values from SSO: for OIDC, xyz is a claim; for SAML, it is an assertion.

Example:

spec:
  allow:
    db_names: ["{{external.databases}}"]

The {{internal.db_users}} and {{internal.db_names}} variables are used in trusted clusters to propagate permitted accounts and database names from the root cluster to the leaf cluster.

Root cluster:

spec:
  allow:
    db_users: ["postgres"]
    db_names: ["postgres"]

Leaf cluster:

spec:
  allow:
    db_users: ["{{internal.db_users}}"]
    db_names: ["{{internal.db_names}}"]

create_db_user_mode option

Automatically create a database user at session start:

ValueDescription
offAuto-creation disabled
keepUser is disabled at the end of the session
best_effort_dropAttempt to drop the user; if it fails, disable instead

With multiple roles, logical OR applies — if at least one role permits it, auto-creation is enabled.

spec:
  options:
    create_db_user_mode: keep

Example: environment separation

kind: role
version: v5
metadata:
  name: db-staging
spec:
  allow:
    db_labels:
      environment: ["staging"]
    db_users: ["app_user", "readonly"]
    db_names: ["app", "analytics"]
  deny:
    db_labels:
      environment: ["prod"]

Create and assign:

airctl create -f db-staging.yaml
airctl users update developer --set-roles=access,db-staging

Connecting to a database

List available databases:

airsh db ls

Connect:

airsh db connect --db-user=readonly --db-name=app postgres-instance