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.
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.
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.
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.
"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.
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.
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.