Airlock uses a role-based access control (RBAC) model. A role contains two rule lists: allow and deny.
- Access is denied by default.
denyrules 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 rolesPreset roles
| Role | Description |
|---|---|
access | Access to cluster resources |
editor | Edit cluster configuration settings |
auditor | Read events, audit logs, and replay sessions |
requester | Create Access Requests |
reviewer | Review and approve Access Requests |
Role versions
Versions v3–v7 are supported. Versions v4 and above are backward compatible with v3; the difference lies in the default values for unset fields.
| Label | v3 default | v4+ 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:
| Option | Description | Behavior with multiple roles |
|---|---|---|
max_session_ttl | Maximum SSH certificate TTL | Minimum TTL |
forward_agent | SSH agent forwarding | Logical OR |
port_forwarding | TCP port forwarding | Logical OR |
ssh_file_copy | SCP/SFTP | Logical AND |
client_idle_timeout | Terminate idle sessions | Minimum value |
require_session_mfa | MFA per session | Logical OR |
pin_source_ip | Bind certificate to source IP | Logical OR |
Creating a role
airctl create -f my-role.yaml
airctl get roles --format textAssign a role to a user:
airctl users update alice --set-roles=access,my-roleDocumentation sections
- SSH hosts — logins, node labels, and SSH session options
- Kubernetes — clusters, groups, users, and Kubernetes resources
- Databases — database labels, accounts, and database names