Configuration

Goldfish takes configurations from two locations. One is a deploy-time json or hcl local file, which cannot be changed without a redeployment. The other is a vault generic secret path, from which Goldfish will read settings from and hot-reload as needed.

Deploy-time configurations

When launching goldfish, provide a local file via -config arg.

Examples

See here for full details on all possible configurations

Listening at port 8000 without TLS

listener "tcp" {
	address          = ":8000"
	tls_disable      = 1
}
vault {
	address         = "http://127.0.0.1:8200"
}

Listening at port 443, with local certificate file

listener "tcp" {
	address          = ":443"
	certificate "local" {
		cert_file = "/path/to/certificate.cert"
		key_file  = "/path/to/keyfile.pem"
	}
}
vault {
	address         = "http://127.0.0.1:8200"
}

Listening at port 443, with a certificate fetched from Vault PKI backend

listener "tcp" {
	address          = ":443"
	pki_certificate "pki" {
		pki_path    = "pki/issue/<role_name>"
		common_name = "goldfish.vault.service"
	}
}
vault {
	address         = "http://127.0.0.1:8200"
}

---

Run-time configurations

Goldfish will read these settings every minute from the runtime_config deployment config. If well-formed, goldfish will hot-reload the settings, and write back Last Updated field.

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

---

Basic [required]

• DefaultSecretPath: the path that is loaded by default on Secrets page
• TransitBackend: the transit backend that goldfish will use for encryption/decryption
• 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??

---

Transit encryption [Optional]

• ServerTransitKey: the key in TransitBackend used to encrypt/decrypt user credentials.
  • Control this tightly (preferably, only allow goldfish to access this) Goldfish can use transit encryption for user credentials

vault mount transit

# initialize the transit key
vault write -f transit/keys/goldfish

# add key 'ServerTransitKey' to goldfish runtime settings
vault write secret/goldfish ServerTransitKey="goldfish" # plus other existing key value pairs

# goldfish will reload settings every minute and start using the key