Configure Boundary controllers for a self-managed deployment, including TLS, KMS, and database parameters. Start the service, authenticate, and manage resources.
In this path, place the Boundary TLS certificate with a Common Name (CN) and Subject Alternate Name (SAN) that matches your planned primary DNS record for accessing the Boundary controllers and any additional SANs as necessary.
In this path, place the Boundary TLS certificate's private key.
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 (also referred to as the scope's root key).
The scope's root KEK and the various DEKs (Data Encryption Keys) are created when a scope is created.
The DEKs are encrypted with the scope's root KEK, and this is in turn encrypted with the KMS key marked for the root purpose.
- **Recovery key**: The recovery KMS key is used for rescue or recovery operations that can be used by a client to authenticate almost any Boundary operation.
A nonce and creation time are included as an encrypted payload, formatted as a token, and sent to the controller.
The time and nonce are used to ensure that a value cannot be replayed by an adversary, and also to ensure that each operation must be individually authenticated by a client, so that revoking access to the KMS has an immediate result.
There are other optional KMS keys that you can configure for different encryption scenarios.
These scenarios include Boundary worker PKI auth encryption and Boundary worker or controller configuration encryption.
Refer to [Data security in Boundary](/boundary/docs/concepts/security/data-encryption) for more information.
<Note>
There are two types of Boundary workers, distinguished by the method by which they authenticate with the Boundary controllers.
One worker uses a PKI exchange to authenticate with the controllers, and the other uses a KMS key that can be used 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:
We recommend that you use either the `env://` or `file://` notation in the configuration files to securely provide secret configuration components to the Boundary controller binaries.
In the following controller configuration example, we use `env://` to declare the PostgreSQL connection string, 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`.
You can use this file to set the sensitive values that are used to configure the Boundary controllers and workers.
The following is an example of how this environment file could be configured:
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.
This operation is only required once; it will execute the required database migrations for the Boundary cluster to operate.
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.
This allows you to configure targets within those scopes and manage them.
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.
