Configuration

Configuration

There are two types of configurations to goldfish.

1. Deploy-time configurations (NOT changeable after launching goldfish)
2. Run-time configurations (hot-reloaded every minute from a specific vault generic endpoint)
   • Set by arg config_path when launching the server
   • As of v0.2.3, goldfish policy needs write access to this path

Deploy-time configurations

• dev: if set to true, goldfish will listen from localhost only, will not enforce https, and ignore many deploy-time settings in favor of a default value
• goldfish_addr: the listening address & port of goldfish.
  • If you're deploying for production, this should just be the https port ":443"
• cert_file: the certificate for the goldfish web server to use to run in https
• key_file: the private key for the matching certificate
• vault_addr: self-explanatory
• vault_token: the wrapping token for the generated secret_id from approle See Here
• approle_path: the approle path in which vault will use to login
  • If you didn't mount approle at some funky location, this can be left empty, and it will default to auth/approle/login
• role_id: the role_id for approle. I would highly recommend leaving as goldfish to avoid confusion
• config_path: a generic backend endpoint where values will be read every minute and hot-reloaded

Run-time configurations

Goldfish will read the provided config_path every minute, and if the changes are well-formed, goldfish will hot-reload the settings.

See the online demo for examples of these settings. Some are optional.

Basic

• DefaultSecretPath: the path that is loaded by default on Secrets page
• TransitBackend: the transit backend that goldfish will use for encryption/decryption
• ServerTransitKey: the key in TransitBackend used to encrypt/decrypt user credentials.
  • Control this tightly (preferably, only allow goldfish to access this)
• UserTransitKey: the key in TransitBackend used by Transit page.
  • Individual users must be granted access to this in order to use the tool.
• BulletinPath: the vault generic backend path that stores bulletins to be displayed. Check the demo for an example
• LastUpdated: when goldfish loads configuration without error, it will try to update this with a timestamp
  • Because this can be overwritten by other operators, it should not be considered a source of truth - it's only a feedback as to whether your configuration was well formed or not

Slack integration [optional]

• SlackWebhook: if a well-formed slack incoming webhook is placed here, new policy change requests will trigger the change ID to be sent to a specified channel. No secret details from the policy will be sent this way.
• SlackChannel: a singular channel or user to notify. E.g. @tonyc or #teamA

GitHub integration [optional]

• GithubAccessToken: for security reasons, either lock down the goldfish config path or create a technical github user with no write privileges to generate this access token. At minimum, this access token should be able to read the repo.
• GithubRepoOwner: this is either the account name or the org name in which the repo is under
  • E.g. caiyeon
• GithubRepo: self-explanatory
  • E.g. goldfish
• GithubPoliciesPath: path in the repo in which the .hcl files reside.
  • E.g. on goldfish repo, this would be vagrant/policies.
  • Only .hcl files will be scanned. Currently .json policy files are not supported.
  • Overwriting default policy by having a default.hcl file is supported. However, if a file is called root.hcl, it will be ignored. Why would you ever do that??

Note: Currently, GithubCurrentCommit and GithubTargetBranch are not used. They are draft properties for a branch and timeline restriction, which is not yet implemented. Right now, it is entirely up to unseal admins to check that the hash matches the correct branch, which they should anyway.