Configuration Providers
Relevant source files
The following files were used as context for generating this wiki page:
Configuration Providers in Warpgate define the mechanism by which the application loads and manages its settings, user credentials, and target host definitions. The system is designed to support different backends for storing these configurations, primarily alternating between a static file-based approach and a dynamic database-backed approach.
Warpgate uses these providers to facilitate the core functionality of acting as a smart bastion host for SSH, HTTPS, MySQL, and PostgreSQL. The configuration determines how the gateway listens for incoming connections, authenticates users against various credential types (TOTP, SSO, Password, Public Key), and routes traffic to internal targets.
Sources: README.md:1-25, warpgate-common/src/config/mod.rs:430-436
Architecture Overview
The configuration architecture is centered around the WarpgateConfigStore and its provider selection. Users can specify the provider type via the config_provider field in the configuration.
The diagram shows the flow from the main application entry point to the population of the configuration store from different provider types.
Sources: warpgate-common/src/config/mod.rs:374-436, warpgate/src/main.rs:90-112
Configuration Provider Types
Warpgate identifies two primary modes for configuration management:
- File Provider: Configurations are read from a YAML file (defaulting to
/etc/warpgate.yaml). This mode is typical for initial bootstrap and static environments. - Database Provider: Configurations for users, roles, and targets are managed dynamically via a database (defaulting to SQLite). This allows the Admin Web UI to modify settings without restarting the service.
Sources: warpgate-common/src/config/mod.rs:430-436, README.md:65-72
Core Configuration Store
The WarpgateConfigStore is the central data structure containing all operational parameters. It includes nested structures for protocol-specific settings and system-wide paths.
Key Configuration Components
| Component | Description | Default Port |
|---|---|---|
SshConfig | Settings for the SSH bastion listener and host keys. | 2222 |
HttpConfig | Web gateway and Admin UI listener settings, including TLS certs. | 8888 |
MySqlConfig | Listener settings for the MySQL protocol proxy. | 3306 |
PostgresConfig | Listener settings for the PostgreSQL protocol proxy. | 5432 |
RecordingsConfig | Paths and toggles for session recording. | N/A |
LogConfig | Log retention policies and export targets. | N/A |
Sources: warpgate-common/src/config/mod.rs:215-372, warpgate/src/commands/setup.rs:115-180
Database Integration
The database provider utilizes sea-orm and sqlx to manage entities. During the setup process, the provider initializes the database schema and creates a default admin user.
The ER diagram illustrates the relationship between users, roles, and targets as managed by the Database Configuration Provider.
Sources: warpgate-admin/src/api/users.rs:180-240, warpgate/src/commands/setup.rs:242-265
Setup and Provisioning
The setup command facilitates the initial creation of the configuration. It supports both interactive prompts and unattended (CLI-driven) modes.
Setup Logic Flow
- Environment Detection: Determines if the app is running in Docker to set appropriate default paths (e.g.,
/data). - Endpoint Configuration: Prompts or accepts CLI arguments for listening IP/ports for HTTP, SSH, and Database protocols.
- Credential Generation: Generates self-signed TLS certificates for HTTP/Database protocols and SSH host keys.
- Admin Initialization: Inserts the initial admin user and roles into the database provider.
The sequence shows the configuration initialization process during the first-time setup.
Sources: warpgate/src/commands/setup.rs:46-300, warpgate/src/main.rs:43-75
Credential Policy Provider
Configuration providers also manage the UserRequireCredentialsPolicy, which dictates what authentication methods are required per protocol.
Authentication Methods
The configuration supports a Union of credential types:
- Password: Hashed using Argon2.
- PublicKey: Standard SSH public keys.
- Totp: Base32 encoded secrets for 2FA.
- SSO: OpenID Connect provider mapping.
Sources: warpgate-common/src/config/mod.rs:22-68
Policy Logic
The provider can dynamically "upgrade" policies. For example, if a user adds a TOTP secret, the provider can update the configuration to require both a Password and TOTP for HTTP access.
pub fn upgrade_to_otp(&self, with_existing_credentials: &[UserAuthCredential]) -> Self {
// ... logic to push Totp requirement if Password exists
}
Sources: warpgate-common/src/config/mod.rs:88-125
Technical Summary
Configuration Providers in Warpgate bridge the gap between static environment settings and dynamic runtime management. By abstracting settings into the WarpgateConfigStore and supporting a robust database backend, the system allows for real-time updates to users and targets via the Admin API while maintaining a stable, file-based bootstrap mechanism.
Sources: warpgate-common/src/config/mod.rs:410-436, README.md:65-80