Access Requests

Access Requests allow users to obtain temporary privilege escalation — to additional roles or specific resources. A request goes through an approval workflow: one or more reviewers approve or deny it.

In Airlock, Access Requests are available through the web interface, the CLI (airsh), and the requester/reviewer roles. This includes role requests, resource requests (SSH, databases, Kubernetes, applications), and approval without requiring an administrator on the Auth Service host.

This approach enforces the principle of least privilege: the number of permanent wide-access administrators decreases, and elevated access is granted only for a limited time and a specific task.

Airlock supports two scenarios:

A single request can contain either roles or resources — mixing both types is not allowed.

requester and reviewer roles

To work with Access Requests, the administrator assigns users the built-in roles:

If your account lacks one of these roles, contact the cluster administrator.

Creating a request via the web interface

Role request

1. In the left panel, select Resources → Access Requests → New Request.
2. In the dropdown, select Roles.
3. Check the required roles and click ADD TO REQUEST.
4. Click PROCEED TO REQUEST, enter a reason, and submit.

Resource request

1. Open Resources → Access Requests → New Request.
2. Select Resources instead of roles.
3. Find the required server, database, application, or Kubernetes object.
4. Add resources to the request, enter a reason, and submit.

Track the request status on the Access Requests page.

Creating a request via airsh

Role request

# Log in to the cluster
airsh login --proxy=airlock.example.com --user=alice

# Create a request for the dba role
airsh request create \
    --roles=dba \
    --reason="database migration tonight"

By default, the command waits for approval. To submit without waiting, add the --nowait flag.

You can request a role directly at login:

airsh login --user=alice --request-roles=dba
# Seeking request approval... (id: bc8ca931-fec9-4b15-9a6f-20c13c5641a9)

After approval, a certificate is issued with the requested role. To log in without waiting, use --request-nowait — regular roles are issued immediately, and elevated access is activated after approval.

Resource request

First, find the resource:

airsh login --proxy=airlock.example.com --user=alice

# Search for SSH nodes (an empty airsh ls list is normal without direct access)
airsh request search --kind node

# Search with a filter
airsh request search --kind node --search iot

Supported resource types: node, kube_cluster, db, app, windows_desktop, and Kubernetes objects (pod, namespace, deployment, and others).

Create a request using the resource ID from airsh request search output:

airsh request create \
    --resource /airlock.example.com/node/b1168402-9340-421a-a344-af66a6675738 \
    --reason="incident response 123"

The command prints the request ID and waits for approval:

Creating request...
Request ID: f406f5d8-3c2a-428f-8547-a1d091a4ddab
Status:     PENDING

Waiting for request approval...

Automatic request on access denial

If resource requests are configured, airsh ssh can create a request automatically when access is denied:

airsh ssh alice@iot
# ERROR: access denied to alice connecting to iot on cluster airlock.example.com
#
# You do not currently have access to alice@iot, attempting to request access.
#
# Enter request reason: need access for diagnostics
# Creating request...
# Waiting for request approval...

After approval, the connection continues without any additional steps.

Reviewing requests

Via the web interface

Users with the reviewer role open Management → Access Requests → Review Requests and see the list of pending requests. Each request can be approved or denied.

Via airsh

airsh login --proxy=airlock.example.com --user=bob

# List requests available for review
airsh request ls --reviewable

# Request details
airsh request show f406f5d8-3c2a-428f-8547-a1d091a4ddab

# Approve
airsh request review --approve f406f5d8-3c2a-428f-8547-a1d091a4ddab

# Deny
airsh request review --deny f406f5d8-3c2a-428f-8547-a1d091a4ddab

A cluster administrator can also review requests via airctl on the Auth Service host if needed:

airctl requests ls
airctl request approve f406f5d8-3c2a-428f-8547-a1d091a4ddab
airctl request deny --reason="task cancelled" f406f5d8-3c2a-428f-8547-a1d091a4ddab

Using an approved request

Via airsh

After approval, log in with the request ID:

airsh login --request-id=f406f5d8-3c2a-428f-8547-a1d091a4ddab

Check the active profile:

airsh status
#   Active requests:    f406f5d8-3c2a-428f-8547-a1d091a4ddab
#   Roles:              access, requester
#   Allowed Resources:  ["/airlock.example.com/node/b1168402-..."]

With a role request, permissions are added to existing ones — the user retains their regular roles plus the approved ones.

With a resource request, the certificate is restricted to the approved resources only — access to other resources is temporarily blocked.

Example of accessing an approved SSH node:

airsh ls
airsh ssh alice@iot

Via the web interface

Open the approved request on the Review Requests page and click ASSUME ROLES (for role requests), or connect to the resource from the Resources section.

While elevated access is active, a banner is displayed at the top of the page. To return to regular permissions, click Switch Back.

Dropping elevated access

When temporary access is no longer needed, drop the active request:

airsh request drop

You can specify a particular ID:

airsh request drop f406f5d8-3c2a-428f-8547-a1d091a4ddab

In the web interface, use the Switch Back button in the active request banner.

Viewing your requests

# All requests for the current user
airsh request ls --my-requests

# Details of a specific request
airsh request show <request-id>

Kubernetes: searching and requesting objects

Search for pods in a cluster:

airsh request search --kind=pod --kube-cluster=mycluster --kube-namespace=default

Request access to a pod:

airsh request create \
    --resource /airlock.example.com/pod/mycluster/development/nginx-1 \
    --reason="application debugging"

To access all pods in a namespace you can use a wildcard or a regular expression:

airsh request create \
    --resource /airlock.example.com/pod/mycluster/*/^nginx-[a-z0-9-]+$

Additional resources