Local file configuration
Most configuration is set in YAML files and loaded directly by the engine. This lets you integrate JumpWire into a GitOps workflow or make quick changes for local testing.
JumpWire Enterprise - all configuration done through the YAML files can instead be set in the web controller.
We strongly recommend only using YAML files OR the web controller for your source of truth, not both at once. Mixing these modes can lead to confusing settings and the engine may not behave the way you expect.
The environment variable JUMPWIRE_CONFIG_PATH must be set to load YAML files. This should be a directory accessible to the JumpWire engine - when using docker, it must be mounted into the container. All files ending in .yml or .yaml from the configured directory and any subdirectories will be parsed and merged together.
Settings that affect the global behavior of the engine.
Required arguments
None
Optional Arguments
- sync - Boolean indicating whether to send objects loaded from the YAML configuration up the web UI for persistence. Default is true
- merge - When set to all, any existing configuration is merged in with the values from this configuration directory. Any other value will cause the existing configuration to be overwritten. Merging should only be disabled if all nodes on the cluster have synchronized configuration files and no changes are made in the web UI. Default is all
- generate_ids - Boolean indicating whether to automatically generate a UUID for any objects that don't have an ID set. The IDs are not persisted back to the YAML file, so enabling this is only intended for testing. Default is false
Connection details for both databases and API endpoints that JumpWire will act as a proxy for.
Required arguments
- id - A UUID to associate with this connection. Optional if generate_ids is enabled.
- name - A human-readable name for the connection.
- root_type - The type of DB or API this connection represents. Valid options are:
- postgresql
- mysql
Optional arguments
- configuration - A map of connection information. The structure for each root_type is documented below.
- credentials - A map of credentials for connecting to the DB or API. The structure for each root_type is documented below.
postgresql configuration
- type (Required) - Must be set to postgresql
- hostname (Required) - Host or IP address of the database. Must be reachable from all JumpWire engine nodes.
- database (Required) - Database to connect to.
- port - TCP port to connect to. Default is 5432
- ssl - Boolean indicating whether to require SSL for the connection from JumpWire to the database. Default is true
- schema - Namespace to use in the database.
mysql configuration
- type (Required) - Must be set to mysql
- hostname (Required) - Host or IP address of the database. Must be reachable from all JumpWire engine nodes.
- database (Required) - Database to connect to.
- port - TCP port to connect to. Default is 3306
- ssl - Boolean indicating whether to require SSL for the connection from JumpWire to the database. Default is truepostgresql credentials
For basic authentication, the following must be set:
- username - Username for connecting to the database.
- password - Password for connecting to the database.
Vault dynamic database credentials can be used by setting:
- vault_database - Name of database to use when dynamically generating credentials from Vault.
- vault_role - Role to read credentials from when using dynamically generated Vault credentials.
mysql credentials
For basic authentication, the following must be set:
- username - Username for connecting to the database.
- password - Password for connecting to the database.
Vault dynamic database credentials can be used by setting:
- vault_database - Name of database to use when dynamically generating credentials from Vault.
- vault_role - Role to read credentials from when using dynamically generated Vault credentials.
Rules for group-based access. Groups and their associated users must be configured through an SSO integration in the web interface.
Each entry is a map with the group name as the key. See below for an example.
Required arguments
None
Optional arguments
- permissions - A list of request attributes that are allowed for the group. Attributes are typically listed as 'action:label'. For example, the attribute select:secret would allow the group to access data labeled as secret but prevent the group from being able to insert/update/delete it. All actions on all labels are blocked by default.
Rules about access and transformation for data being proxied.
Required arguments
- id - A UUID to associate with this policy. Optional if generate_ids is enabled.
- name - A human-readable name for this policy.
- handling - The action to take when the policy is applied. Valid values are:
- access - Allow the request to occur.
- block - Prevent the request.
- drop_field - Replace the labeled field with a null value.
- audit - Generate an audit record of the request.
- encrypt - Encrypt or decrypt the labeled field.
- resolve_fields - Replace the value of the labeled field with a different value using a KV store.
Optional arguments
- version - The version of the policy schema. Default is 2
- attributes - A list of groups of attributes defining when this policy is applied. Default is []
- apply_on_match - When true, the policy will be applied when its attributes match the request. When false, the policy will be applied to all requests that don't match its attributes. Default is false
- configuration - Map of additional options that must be set for some handling types. See the documentation below.
resolve_fields configuration
- type (Required) - Must be set to resolve_fields
- metastore_id (Required) - UUID of the KV store to use for looking up field values.
- route_key (Required) - The field to use when determining whether this KV store should be used.
- route_values (Required) - A list of values for the route_key field indicating that this KV store should be used.
Fields and associated labels. Each schema is specific to a single DB or API connection.
Required arguments
- id - A UUID to associate with this schema. Optional if generate_ids is enabled.
- name - A human-readable name for the schema.
- manifest_id - The UUID of the DB or API that this schema pertains to.
- fields - Mapping of field names to their label. Fields without a label do not need to be explicitly configured.
Optional arguments
None
Connections details for backends used as KV stores.
Required arguments
- id - A UUID to associate with this connection. Optional if generate_ids is enabled.
- name - A human-readable name for the connection.
- configuration - A map specific to the type of KV store being configured. See the documentation below for possible structures.
Optional arguments
- vault_database - Name of database to use when dynamically generating credentials from Vault. If set, vault_role must also be set.
- vault_role - Role to read credentials from when using dynamically generated Vault credentials. If set, vault_database must also be set.
- credentials - A map of credentials for connecting to the DB or API. The structure for each KV type is documented below. Either credentials or vault_database and vault_role should be set, but not both.
postgresql_kv configuration
Configuration to use a PostgreSQL database as a KV store when performing lookups on proxied queries.
- type (Required) - Must be set to postgresql_kv
- connection (Required)
- hostname (Required) - Host or IP address of the database. Must be reachable from all JumpWire engine nodes.
- database (Required) - Database to connect to.
- port - TCP port to connect to. Default is 5432
- ssl - Boolean indicating whether to require SSL for the connection from JumpWire to the database. Default is true
- schema - Namespace to use in the database.
- table (Required) - The table containing key/value information.
- key_field (Required) - The field in the configured table containing the lookup key.
- value_field (Required) - The field on the configured table containing the value for that row.
