Security
Managing secrets
Generally, when defining either connections or authentication tokens you need to store sensitive values.
As Orbital is built around file-based and git-based data stores, these are values you generally don’t want checked in.
Environment variables
All Orbital config files are defined in HOCON format, which allows for variable substitution from the environment.
When deploying Orbital into production, it’s recommended to keep secrets in a secret store (eg., Vault), and inject them into the environment as part of the machine provisioning process.
Orbital will correctly inject these values into placeholders.
Using env.conf for sensitive data
In addition to the standard HOCON rules for resolving variables, Orbital supports
the use of a env.conf
file as a source for substitutions.
This can be useful when developing locally, to ensure that sensitive values aren’t accidentally checked in, but to avoid having to configure environment variables, which can be fiddly.
The general workflow is as follows:
- Define a
connections.conf
file with your connections, using${variables}
for placeholders of sensistive data. - Create a local
env.conf
file. - The location of the
env.conf
file must be along side theconnections.conf
file - ie., the path defined in your taxi.conf file - Populate the env.conf file with sensitive values.
Eg:
jdbc {
my-connection {
// ... other params omitted for brevity ...
connectionParams {
password = ${postgres_password} // Reads the environment variable "postgres_password"
}
}
}
postgres_password=hello123