Production setup documentation

Hi. Perhaps I’m just doing a bad job of searching, but I am having a hard time with writing a basic setup and the documentation is where I’m falling short. I am, for example, seeing a default configuration that refers to kms keys, but no real explanation or understanding of the attributes in that stanza. I’m seeing we need to build a postgres backend but I don’t see a deployment instruction for that db. I’m also seeing hcl not behave as it does with terraform (eg: no variables, ordering problems).

So I guess, in general, I’m having trouble getting a beta even running, and I could use a pointer to the documentation that might help me past these hurdles in order to proceed. The product is a much-needed relief for us and I’d love to get kicking the tires.

1 Like

Thanks for trying out Boundary @aardvarq.

For KMS, have you looked at

For postgres information, take a look at Generally, any PG version 11 or greater will do.

Regarding the HCL: HCL is an interchange format (like JSON and YAML) and Terraform adds to it by using it as a declarative configuration language. Terraform is to HCL as Ansible is to YAML.

Thanks again for trying this out and let us know if you have any other questions.

Many thank-yous, I will.


For kms, where is the key generated? Is it anticipated that I might terraform this and then pass the decrypted key to the config? Can I do that dynamically?

For postgres, I am still confused. I see instructions that “In non-HA configurations, this means boundary servers”. I don’t know what that means. Is that a zero-config item? For HA, it directs to an architecture diagram but I still don’t seem to see anything that would guide me to creating a database or if I even need to explicitly.

Thanks for reading.

Have found the database install command section. I still am a bit confused about the KMS section. I gather I am to pre-seed these keys, but I’m curious about the hard-coded credentials in the config. Is this something that can be configured to be pulled at runtime or cached in some other way?

We support many types of KMS providers, including all the major clouds, as well as hard coding an AEAD key (as we do in our examples for simplicity). Hard coding the key is for demonstration purposes mostly, we expect that if you’re running Boundary in a secure environment that you’ll opt out of hard coding the key and prefer a real KMS provider instead.

I guess I must not be reading this correctly.

"This example shows configuring AWS KMS through the Boundary configuration file by providing all the required values:

And then the file exposes a bunch of information I don’t wish to configure.

I’m expecting something analogous to terraform, I suppose. In terraform, I’d assign the values in data sourcing or possibly variables passed in via a CI pipeline.

I’m missing something; what?

You didn’t say what information specifically you don’t want to configure. You can of course write out a Boundary config file using some templating, including (I think) Terraform, and you can also source information through normal AWS credential chain means. In most cases that’s how people configure it, only specifying static information if they want to override values.

Hi Jeff, thanks. You’re right, sorry - I was implying the AWS credential strings in this case.

Using terraform outputs to template is a good idea, I hadn’t really thought of that but it seems like the way to go. Appreciate the support.

I’d like to use an instance profile in AWS to fetch the kms key, but it seems that AWS credentials must be provided in the kms stanza - which would suggest we cannot do this transparently; is that correct? Instead, I’d need to grab credentials from the instance metadata and drop them into the configuration?

Check out the AWS KMS access key configuration docs. If you’re setting the key and key ID via env vars or via instance metadata (an instance profile), it’ll read them in, no need to set them in the configuration file itself.

There’s a good example of this in our reference architecture AWS deployment.

That’s the very documentation I’m reading.

access_key, secret_key, and kms_key_id are all stated to be ‘required’ by the configuration file.

I imagine that is incorrect, then.