Configure Boundary controllers for a self-managed deployment, including TLS, KMS, and database parameters. Start the service, authenticate, and manage resources.
Place the Boundary TLS certificate with a Common Name (CN) and Subject Alternate Name (SAN) that matches your planned primary DNS record in this path so that the Boundary controllers and any SANs can access it.
If you do not generate unique TLS key material for each node, you should securely distribute the key material to each of the Boundary controller nodes.
## Prepare KMS keys
Boundary controllers require the two following different cryptographic keys:
- **Root key**: The root KMS key acts as a KEK (Key Encrypting Key) for the scope-specific KEKs, which are also referred to as the scope's root keys.
When you create a scope, Boundary also creates the root KEK and the various DEKs (Data Encryption Keys).
It encrypts the DEKs using the scope's KEK, and then encrypts the KEK with the KMS key marked for the root purpose.
- **Recovery key**: You use the recovery KMS key to authenticate Boundary client rescue and recovery operation workflows.
The recovery key includes a nonce and creation time as an encrypted payload.
Boundary formats the payload as a token and sends it to the controller.
The time and nonce ensure that an adversary cannot replay a value, and also ensure that a client must individually authenticate each operation, so that revoking access to the KMS has an immediate result.
One worker uses a PKI exchange to authenticate with the controllers. The other uses a KMS key for authentication by both the worker and the controller.
You use the Worker-auth key listed above to enable KMS worker authentication.
</Note>
HashiCorp strongly recommends that you use either Vault Transit or your cloud provider's key management system.
Refer to the [Vault Transit](/vault/docs/secrets/transit) documentation or your cloud provider's key management documentation for more information.
After you create the keys in Vault or the key management system of your choice, you can prepare the PostgreSQL database.
## Prepare the database
Boundary manages its state and configuration in a Relational Database Management System (RDBMS), PostgreSQL.
You should create, set up, and make the PostgreSQL database accessible to the Boundary controller nodes before you configure the nodes.
Refer to the [Database recommendations](/boundary/docs/install-boundary/system-requirements#database-recommendations) documentation for examples of cloud managed PostgreSQL databases.
## Create the controller configuration
Once you have configured the following, you can create the controller configuration:
- At least three virtual machines with Boundary installed on them
- At least one TLS certificate and key to distribute to the virtual machines for TLS communication
- KMS keys to use for at least root and recovery operations
- A PostgreSQL database to manage configuration and state
You must complete the following controller configuration for each of the Boundary controller nodes.
### Base controller configuration
The core required values for a Boundary controller configuration include the following:
HashiCorp recommends that you use either the `env://` or `file://` notation in the configuration files to securely provide secret configuration components to the Boundary controller binaries.
The following controller configuration example uses `env://` to declare the PostgreSQL connect strings as well as secure the AWS KMS configuration items.
When you install the Boundary binary using a package manager, it includes a unit file that configures an environment file at `/etc/boundary.d/boundary.env`.
In the example above, the proper IAM roles and permissions for the given `AWS_ACCESS_KEY` and `AWS_SECRET_ACCESS_KEY` must be in place so that Boundary can use them to access the different KMS keys.
Next, populate the `controller.hcl` file with any relevant configuration information.
The following example configuration file is a good starting point for a production Boundary controller installation.
It defines the three `listener` blocks, two unique `kms` blocks that are specific to AWS (as an example), the `disable_mlock` value, and the `controller` block.
Refer to the documentation for additional [top-level configuration options](/boundary/docs/configuration) and additional [controller-specific options](/boundary/docs/configuration/controller).
## Initialize the database
Before you can start Boundary, you must initialize the database from one Boundary controller.
Unless you configure it not to, Boundary automatically generates a number of resources to make getting started easier. It automatically generates default scopes, auth methods, user, account, and targets. These
When the configuration files are in place on each Boundary controller, you can proceed to enable and start the binary on each of the Boundary controller nodes using `systemd`.
Upon logging in to Boundary for the first time, HashiCorp recommends creating an admin user for the global and project level scopes to manage Boundary.
HashiCorp recommends that you use the [KMS recovery workflow](/boundary/docs/install-boundary/initialize#log-in-with-recovery-kms) to log in to Boundary for the first time.
Refer to [Creating your first login account](/boundary/docs/install-boundary/initialize#create-your-first-login-account) to learn about setting up your first auth method, user, account, and role to log in to Boundary going forward without the recovery KMS workflow.
