Security Policy & Threat Model
Relevant source files
The following files were used as context for generating this wiki page:
Warpgate is a smart bastion host designed for Linux that facilitates secure SSH, HTTPS, MySQL, and PostgreSQL connections without requiring specialized client applications. It is written in 100% safe Rust and operates by receiving connections with specific credentials, authenticating users locally, and then proxying traffic to target hosts while optionally recording the session.
The security model of Warpgate relies on a zero-trust approach toward target traffic, strictly enforced credential policies, and a controlled administrative interface. It supports native 2FA (TOTP) and SSO (OpenID Connect) to enhance the security posture of the DMZ environment it inhabits.
Sources: README.md:1-25, SECURITY.md:1-20
Trust Boundaries and Attack Surface
Warpgate defines specific inputs and infrastructure components as "trusted" or "untrusted." The system is designed to operate in a DMZ, acting as a gateway between external users and internal network resources.
Trusted vs. Untrusted Inputs
| Input Category | Trust Level | Description |
|---|---|---|
| Connected Database | Trusted | Contents of the SQLite or external database used for configuration and session history. |
| Config File | Trusted | Local configuration files, provided file permissions are correctly locked down. |
| Admin HTTP Requests | Trusted | Requests made by users previously authenticated with the warpgate:admin role. |
| Target Infrastructure | Trusted | The actuality and stability of target IPs/hostnames within the internal network. |
| Target Traffic | Untrusted | Traffic originating from known Warpgate targets is explicitly considered untrusted. |
Sources: SECURITY.md:12-20
Connection Flow Architecture
The following diagram illustrates how Warpgate sits between the user and the target, establishing separate encrypted legs for each connection.
Warpgate does not act as a jump host; it forwards connections straight to the target after local authentication.
Sources: README.md:10-25, warpgate/src/commands/setup.rs:250-300
Authentication and Credential Management
Warpgate implements a multi-layered authentication system. Users are assigned roles, and access to targets is granted based on these role assignments.
Credential Types
Warpgate supports several credential types for both user-to-Warpgate and Warpgate-to-target authentication:
- Password: Traditional password-based auth, hashed using Argon2.
- Public Key: SSH public keys for user authentication and Warpgate's own keys for target access.
- TOTP: Native two-factor authentication.
- SSO: Integration with OpenID Connect providers.
Sources: warpgate-web/src/admin/CredentialEditor.svelte:1-20, warpgate-web/src/admin/lib/openapi-schema.json:780-820
Security Policies (Credential Policy)
Administrators can define a UserRequireCredentialsPolicy per user and per protocol (SSH, HTTP, MySQL, PostgreSQL). This allows enforcing multi-factor authentication (e.g., requiring both a Password and TOTP for HTTP access).
Supply Chain & Dependency Security
Warpgate uses cargo-deny to manage its dependency tree and mitigate supply chain attacks. The configuration enforces strict license compliance and bans specific crates known for security risks or maintenance issues.
Banned Components
- openssl-sys: Explicitly denied to favor Rust-native TLS implementations (rustls).
- Unmaintained Crates: Crates like
ansi-termandpasteare flagged or ignored specifically due to their maintenance status. - Feature Restrictions: Certain features of
reqwestandrustlsare restricted to ensure a specific security profile (e.g., denyingrustls-tls-webpki-rootsin some contexts).
Sources: deny.toml:90-130
License Compliance
Warpgate allows only specific OSI-approved licenses (MIT, Apache-2.0, ISC, etc.) to ensure the legal integrity of the binary distribution.
Sources: deny.toml:200-220
Transport Security (TLS/SSH)
Warpgate enforces encryption for both administrative access and proxied traffic.
Certificate Management
During initial setup, Warpgate generates self-signed TLS certificates for the HTTP, MySQL, and PostgreSQL listeners if custom ones are not provided.
// warpgate/src/commands/setup.rs:356-360
info!("Generating a TLS certificate");
let cert = generate_simple_self_signed(vec![
"warpgate.local".to_string(),
"localhost".to_string(),
])?;
The setup process also creates unique SSH host and client keys, ensuring that the bastion has its own identity when connecting to targets.
Sources: warpgate/src/commands/setup.rs:356-373, warpgate/src/commands/setup.rs:260-265
Target Security Options
When configuring targets, administrators can specify TLS verification modes:
- Disabled: No encryption.
- Preferred: Encrypt if the target supports it.
- Required: Connection fails if TLS cannot be established.
Sources: warpgate-web/src/admin/lib/openapi-schema.json:1440-1460
Administrative Access Control
The Warpgate admin interface is protected by a built-in role system.
- warpgate:admin Role: A reserved role that grants full control over targets, users, and session recordings.
- API Security: The backend API uses two primary security schemes:
TokenSecurityScheme: An API key passed in theX-Warpgate-Tokenheader.CookieSecurityScheme: A session cookie namedwarpgate-http-session.
- Tickets: Warpgate supports short-lived, single-use, or multi-use "tickets" that grant access to specific targets without requiring permanent user credentials.
Sources: warpgate-web/src/admin/lib/openapi-schema.json:1530-1545, warpgate/src/commands/setup.rs:275-285, warpgate-web/src/admin/lib/openapi-schema.json:1260-1285
Vulnerability Reporting
Security vulnerabilities should be reported through GitHub's Private Vulnerability Reporting tool rather than public issues. The project maintainers commit to responding within a few days.
Sources: SECURITY.md:1-7, README.md:75-77
Summary
Warpgate's security model centers on being a hardened gateway that minimizes the exposure of internal services. By utilizing Rust's memory safety, enforcing granular credential policies, and auditing all sessions through recordings and logs, it provides a secure alternative to standard jump hosts. The strict management of dependencies via cargo-deny further protects against upstream supply chain vulnerabilities.