Authentication and Authorization
Airlock handles both authentication and authorization:
- Authentication — verifying the identity of a user or service.
- Authorization — checking access rights to a resource.
This document describes authentication using short-lived certificates.
Short-Lived Certificates
Certificate authorities (CAs) and short-lived certificates are the foundation of Airlock authentication. At the start of every connection, a user or service presents a valid certificate issued by a trusted CA. Clients always initiate mutual TLS or SSH authentication.
The Airlock CA issues short-lived X.509 certificates for web services, databases, Kubernetes clusters, desktops, and SSH certificates for OpenSSH-compatible servers.
Advantages of Certificates
- Certificates are bound to a user or service identity — every action is traceable.
- Short-lived certificates expire automatically; revocation is not required.
- Certificates solve the Trust On First Use (TOFU) problem: all servers in the cluster have their own identities and certificates and do not accept client certificates signed by an untrusted CA.
- Certificates provide mutual authentication (mTLS), reducing the risk of impersonation, man-in-the-middle attacks, and credential brute-forcing.
- Certificates scale better: each service only needs to verify the CA signature, without copying credentials to every node.
Airlock issues certificates with lifetimes ranging from a few hours to a few minutes. The shorter the lifetime, the better. Ideally, issue a certificate only for the duration of a session. In practice, a few hours or a working day is acceptable. The expiry date in a certificate cannot be forged without invalidating it.
X.509 Certificates
X.509 certificates are the same certificates used when accessing websites through a browser. They bind an identity to a public key with a CA signature.
Airlock uses X.509 for Kubernetes, databases, web services, and internal components (proxy, Auth Service) to establish mutual TLS authentication (mTLS).
OpenSSH Certificates
SSH certificates are similar to X.509 and also bind a user or server identity to a public key with a CA signature.
An SSH certificate contains metadata for authentication:
- A list of principals (identities) that the certificate belongs to.
- The signature of the CA that issued the certificate.
- An expiry date (TTL).
- Additional data (e.g., node role) in certificate extensions.
Time as a Security Factor
Expiration is a built-in property of certificates. SSH and X.509 certificates contain an expiry date that servers verify alongside the signature.
Airlock issues certificates with lifetimes from a few hours down to minutes; upon expiry they automatically become invalid. Instead of revocation lists, Airlock relies on time.
If certificate expiration is insufficient (for example, during a security incident), Proxy Service can immediately terminate active connections using session and identity locking.
User Certificates
To issue a certificate to a user, Airlock presents a login screen, issues the certificate, and delivers it to the user’s computer.
Using SSO (GitHub, SAML, OIDC, or another identity provider) to obtain a short-lived certificate is recommended.
Internal Certificates
Internal Airlock services — Auth, Proxy, and nodes — use certificates to identify themselves within the cluster. To connect proxies and nodes to the cluster, administrators use short-lived join tokens.
Unlike users, internal services receive long-lived certificates. To renew them, administrators perform CA rotation — revoking all previously issued certificates regardless of their expiry and issuing new ones with a new CA.
To quickly lock a compromised node, proxy, or Auth Service without rotating certificates for the entire cluster, use session and identity locking.