Local users

In Airlock, any local, SSO, or bot user can be assigned one or more roles. Roles determine access to databases, SSH servers, Kubernetes clusters, Windows desktops, and web applications.

Local users are accounts managed directly through Airlock rather than through an external identity provider. All local users are stored in the cluster state backend: name, roles, traits, and a bcrypt-hashed password.

Preset roles

Airlock provides several preset roles:

Adding local users

Use the airctl utility to manage local users. Add user Alice with the editor role:

airctl users add alice --roles=editor

You can specify multiple roles and permitted OS logins if needed:

airctl users add joe --logins=joe,root --roles=access,editor

Airlock generates a one-time invitation link (valid for one hour). The user follows the link, sets a password, and configures MFA if required. After registration, the account appears in the list:

airctl users ls

Example output:

User                 Roles
-------------------- --------------
alice                editor
joe                  access, editor

Updating roles

Update a user’s roles with airctl users update:

airctl users update alice --set-roles=editor,auditor

If a user has multiple roles, permissions are combined (logical OR). A user can simultaneously act as an administrator and an auditor.

Editing and deleting

Retrieve a user definition for editing:

airctl get user/joe > joe.yaml
# edit joe.yaml
airctl create -f joe.yaml

Delete a local user:

airctl users rm joe

Creating a custom role

Create a role for interns with access to test and staging SSH servers, monitoring applications, and the dev Kubernetes cluster.

Save the role to interns.yaml:

kind: role
version: v6
metadata:
  name: interns
spec:
  allow:
    logins: ['readonly']
    kubernetes_groups: ["view"]
    node_labels:
      'env': ['staging', 'test']
    kubernetes_labels:
      'env': 'dev'
    kubernetes_resources:
      - kind: 'pod'
        namespace: "*"
        name: "*"
    app_labels:
      'type': ['monitoring']
  deny:
    node_labels:
      'env': 'prod'
    kubernetes_labels:
      'env': 'prod'
    kubernetes_resources:
      - kind: 'pod'
        namespace: 'prod'
        name: '*'
    db_labels:
      'env': 'prod'
    app_labels:
      'env': 'prod'

Create the role:

airctl create -f interns.yaml
airctl get roles --format text

RBAC principles

An Airlock role contains two rule lists: allow and deny.

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

Access to resources is configured through labels on resources and corresponding rules in the role. Multiple labels in a single rule are interpreted as a logical AND.

Lockout after failed login attempts

A local user is locked for 20 minutes if there are several failed login or password reset attempts within a 30-minute window.

An administrator with user resource permissions (the editor role) can unlock the user:

airctl get users/alice > user.yaml

Edit the status.is_locked field to false and apply the changes:

airctl create -f user.yaml

Next steps

• Configure OIDC or SAML for single sign-on
• Enable OTP or WebAuthn for two-factor authentication
• Review access policies for SSH, Kubernetes, and databases