This document describes the core concepts and components of an Airlock deployment. These terms appear throughout the platform configuration and operation documentation.
Airlock Cluster
The central concept in Airlock’s architecture is the cluster. A cluster consists of Auth Service and Proxy Service, along with Airlock services that manage access to infrastructure resources: Kubernetes clusters, Windows desktops, databases, and applications.
A minimal cluster includes Auth Service and Proxy Service. In a demo environment, both services can run as a single airlock process on a Linux host.
For details on how components interact: Component Interaction.
Auth Service
Auth Service manages local users and configuration resources for the cluster. It maintains certificate authorities (CAs) that allow users and services to authenticate to the cluster. Auth Service issues certificates to clients and maintains an audit log.
Auth Service is the only cluster component that requires a backend connection for storing cluster state and CA private keys. Airlock services are stateless and communicate with Auth Service via the gRPC API.
For high availability, you can run multiple Auth Service instances.
See also: Authentication, Authorization.
Proxy Service
Proxy Service provides secure access to infrastructure resources from a public network without a VPN.
It establishes reverse tunnels to Auth Service and Airlock services that may run in private networks. In a minimal configuration, only port 443 needs to be exposed to the internet, while the rest of the infrastructure stays in a private network.
For production, you can run multiple Proxy Service instances behind a load balancer — this increases availability, distributes load, and reduces latency by placing proxies closer to users or agents.
Clients can also connect to resources directly using Airlock certificates, bypassing Proxy Service.
See also: Proxy Service.
Airlock Services
An Airlock service manages access to infrastructure resources. A single airlock process can run one or more services depending on the configuration.
Application Service
Proxies HTTP and TCP traffic to configurable endpoints — internal web applications and other services.
Database Service
Proxies TCP traffic using the native protocols of popular databases, including PostgreSQL and MySQL.
Desktop Service
Proxies Remote Desktop Protocol (RDP) traffic to Windows desktops.
Kubernetes Service
Proxies HTTP traffic to the Kubernetes API server.
SSH Service
An SSH server implementation that allows executing commands on remote machines with built-in access control, auditing, and session recording.
Agent
An instance of an Airlock service is called an agent. For all services except SSH Service, a single agent can provide access to multiple resources and run on a separate host from the target resources. All agents must be in the same network as their target resources.
Configuration Resources
A configuration resource is a document stored in the Auth Service backend that defines cluster parameters. Examples: roles, local users, authentication connectors.
Role
A role is a configuration resource that grants Airlock users privileges in the cluster. RBAC in Airlock denies access by default: users need explicit permissions to access a resource or perform administrative actions.
Airlock Users
Airlock supports two types of users:
- Local users — correspond to a
userresource stored in the Auth Service backend. - SSO users — stored in an external identity provider (GitHub, SAML, OIDC). When authenticating via SSO, Airlock issues a certificate and creates a temporary local user for the duration of the certificate.
Ultimately, an Airlock user is the subject of a certificate issued by Auth Service. Auth Service verifies the presence of a valid Airlock certificate and uses the certificate subject — username and roles — for authorization.
Authentication Connector
An authentication connector is a configuration resource that allows users to log into Airlock through an external identity provider (SSO).
Trusted Clusters
Airlock supports a trusted cluster relationship between a root cluster and one or more leaf clusters that trust the root cluster’s CA. Users authenticated to the root cluster can access resources in a leaf cluster. Root and leaf clusters operate independently with their own users, roles, and resources; the trust relationship allows mapping root cluster roles to leaf cluster roles and permissions.