Airlock uses a role-based access control (RBAC) model. A role contains two rule lists: allow and deny.

  • Access is denied by default.
  • deny rules are checked first and take priority.

Roles and other dynamic resources are managed through the Airlock web interface, the airctl utility, or the API.

Viewing roles

airsh login --user=admin --proxy=airlock.example.com
airctl get roles

Preset roles

RoleDescription
accessAccess to cluster resources
editorEdit cluster configuration settings
auditorRead events, audit logs, and replay sessions
requesterCreate Access Requests
reviewerReview and approve Access Requests

Role versions

Versions v3v7 are supported. Versions v4 and above are backward compatible with v3; the difference lies in the default values for unset fields.

Labelv3 defaultv4+ default
node_labels[{"*": "*"}] when logins are present, otherwise [][]
app_labels[{"*": "*"}][]
kubernetes_labels[{"*": "*"}][]
db_labels[{"*": "*"}][]

Version v6 added the kubernetes_resources field for fine-grained control over Kubernetes resources.

RBAC for infrastructure resources

A role defines which resources (applications, servers, databases) a user can access. The mechanism: labels on resources combined with allow/deny rules in a role.

Example: infrastructure is divided by labels environment=production and environment=staging. An intern’s role may allow access only to environment=staging.

Example role with labels

kind: role
version: v5
metadata:
  name: example-role
spec:
  allow:
    node_labels:
      'env': 'stage'
  deny:
    node_labels:
      'workload': ['database', 'backup']

Multiple labels in a single rule are interpreted as a logical AND:

    db_labels:
      'env': 'prod'
      'region': ['eu-central-1', 'eu-west-1']

Extended label syntax

kind: role
version: v5
metadata:
  name: example-role
spec:
  allow:
    node_labels:
      'environment': 'test'
      '*': '*'
      'environment': ['test', 'staging']
      'environment': '^test|staging$'

Role options

Options constrain session parameters. When a user has multiple roles, combined rules apply:

OptionDescriptionBehavior with multiple roles
max_session_ttlMaximum SSH certificate TTLMinimum TTL
forward_agentSSH agent forwardingLogical OR
port_forwardingTCP port forwardingLogical OR
ssh_file_copySCP/SFTPLogical AND
client_idle_timeoutTerminate idle sessionsMinimum value
require_session_mfaMFA per sessionLogical OR
pin_source_ipBind certificate to source IPLogical OR

Creating a role

airctl create -f my-role.yaml
airctl get roles --format text

Assign a role to a user:

airctl users update alice --set-roles=access,my-role

Documentation sections

  • SSH hosts — logins, node labels, and SSH session options
  • Kubernetes — clusters, groups, users, and Kubernetes resources
  • Databases — database labels, accounts, and database names