CyberCoveLLC/threshold
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: IA reorganization (#5838)

Browse Source 
* docs: IA reorganization

* docs: Updates

* docs: Updates

* docs: Fix links

* docs: Updates

* docs: Fix a typo

* docs: Fix client agent topic

* docs: Update Client Agent nav

* docs: Fix conflict

* docs: Fix a typo in Client Agent docs (#5853)

* docs: Fix client agent topic

* docs: Updates

* docs: Updates

* docs: Updates

* docs: Updates

* docs: Fixes get started and operations links

* docs: Update nav

* docs: Partials

* docs: Unix partials

* docs: Worker partials

* docs: Updates

* docs: Update workers and targets

* docs: Updates

* docs: Updates

* docs: Fixes link

* docs: Updates after sync review

* docs: Updates from review feedback

* docs: Move worker filter examples

* docs: Fix links

* docs: Updates for filters based on working session

* docs: Fixes broken links

* docs: Add links to other filter topics

* docs: Update list intro

* docs: Adds link

* docs: Fixes redirects

* docs: Fixes redirects

* docs: Deleted mysql page from TOC

* docs: Add versioned redirect

* docs: Adds versioned redirects

* docs: Adds versioned redirects

* docs: Update redirects

* docs: Update redirects

* docs: Redirect fixes

* docs: Update redirect format

* docs: Fix a typo

* docs: Fixes redirects

* docs: Fixes redirect

* docs: Adds links out to client agent troubleshooting

* uses /etc/boundary.d/ as recommended installation directory (#6003)

* docs: Updates legacy io links

* docs: Fixes redirects

* docs: Fix redirect

* docs: Restoring deleted file

---------

Co-authored-by: Robin Beck <stellarsquall@users.noreply.github.com>
This commit is contained in:
Dan HeathandRobin Beck authored and GitHub committed 2025-09-03 15:45:38 -04:00
1 parent 21fce7c5eb
commit 5ce6515156
253 files changed
+7897 -5673
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

website/content/docs/deploy/self-managed/configure-controllers.mdx
+350
View File
@@ -0,0 +1,350 @@
---
layout: docs
page_title: Configure controllers
description: >-
Configure Boundary controllers for a self-managed deployment, including TLS, KMS, and database parameters. Start the service, authenticate, and manage resources.
---
# Configure controllers
Refer to the following sections to configure your Boundary controllers.
## Prepare TLS certificates
HashiCorp recommends that the Boundary controller nodes handle TLS using PKI for user connections.
Further, we strongly recommend that you use certificates that an appropriate certificate authority (CA) generated and signed.
To use TLS, you must have two files on each Boundary controller node.
You may have to create a new directory to store the certificate material at `/etc/boundary.d/tls`.
Place the files in the following paths:
- `/etc/boundary.d/tls/boundary-cert.pem`
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.
- `/etc/boundary.d/tls/boundary-key.pem`
Place the Boundary TLS certificate's private key in this path.
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.
The following keys are optional:
- **Worker-auth key (Optional)**: The controller and worker share the worker-auth KMS key to authenticate a worker to the controller.
If a worker uses PKI authentication, this key is unnecessary.
- **BSR key (Optional)**: Session recording requires the BSR KMS key.
Boundary uses the BSR key for encrypting data and checking the integrity of recordings.
If you do not add a BSR key to your controller configuration, you receive an error when you try to enable session recording.
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 encryption in Boundary](/boundary/docs/secure/encryption/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. 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/architecture/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:
- `listener` blocks for `api`, `cluster`, and `ops`
- A `kms` block
- `disable_mlock`
- A `controller` block
When you install Boundary from the HashiCorp Linux Repository, it installs some example configuration files under `/etc/boundary.d/`.
Run the following commands to rename the example configuration files:
1. `sudo mv boundary.hcl boundary.hcl.old`
1. `sudo mv controller.hcl controller.hcl.old`
1. `sudo mv worker.hcl worker.hcl.old`
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`.
You can use this file to set the sensitive values used to configure the Boundary controllers and workers.
The following is an example of a configuration using this environment file:
<CodeBlockConfig lineNumbers filename="/etc/boundary.d/boundary.env">
```shell-session
POSTGRESQL_CONNECTION_STRING=postgresql://boundary:boundary@postgres.yourdomain.com:5432/boundary
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
```
</CodeBlockConfig>
<Note>
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.
</Note>
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.
<CodeBlockConfig lineNumbers filename="/etc/boundary.d/controller.hcl">
```hcl
# disable memory from being swapped to disk
disable_mlock = true
# API listener configuration block
listener "tcp" {
# Should be the address of the NIC that the controller server will be reached on
# Use 0.0.0.0 to listen on all interfaces
address = "0.0.0.0:9200"
# The purpose of this listener block
purpose = "api"
# TLS Configuration
tls_disable = false
tls_cert_file = "/etc/boundary.d/tls/boundary-cert.pem"
tls_key_file = "/etc/boundary.d/tls/boundary-key.pem"
# Uncomment to enable CORS for the Admin UI. Be sure to set the allowed origin(s)
# to appropriate values.
#cors_enabled = true
#cors_allowed_origins = ["https://yourcorp.yourdomain.com", "serve://boundary"]
}
# Data-plane listener configuration block (used for worker coordination)
listener "tcp" {
# Should be the IP of the NIC that the worker will connect on
address = "0.0.0.0:9201"
# The purpose of this listener
purpose = "cluster"
}
# Ops listener for operations like health checks for load balancers
listener "tcp" {
# Should be the address of the interface where your external systems'
# (eg: Load-Balancer and metrics collectors) will connect on.
address = "0.0.0.0:9203"
# The purpose of this listener block
purpose = "ops"
tls_disable = false
tls_cert_file = "/etc/boundary.d/tls/boundary-cert.pem"
tls_key_file = "/etc/boundary.d/tls/boundary-key.pem"
}
# Controller configuration block
controller {
# This name attr must be unique across all controller instances if running in HA mode
name = "boundary-controller-1"
description = "Boundary controller number one"
# This is the public hostname or IP where the workers can reach the
# controller. This should typically be a load balancer address
public_cluster_addr = "example-cluster-lb.example.com"
# Enterprise license file, can also be the raw value or env:// value
license = "file:///path/to/license/file.hclic"
# After receiving a shutdown signal, Boundary will wait 10s before initiating the shutdown process.
graceful_shutdown_wait_duration = "10s"
# Database URL for postgres. This is set in boundary.env and
#consumed via the “env://” notation.
database {
url = "env://POSTGRESQL_CONNECTION_STRING"
}
}
# Events (logging) configuration. This
# configures logging for ALL events to both
# stderr and a file at /var/log/boundary/controller.log
events {
audit_enabled = true
sysevents_enabled = true
observations_enable = true
sink "stderr" {
name = "all-events"
description = "All events sent to stderr"
event_types = ["*"]
format = "cloudevents-json"
}
sink {
name = "file-sink"
description = "All events sent to a file"
event_types = ["*"]
format = "cloudevents-json"
file {
path = "/var/log/boundary"
file_name = "controller.log"
}
audit_config {
audit_filter_overrides {
sensitive = "redact"
secret = "redact"
}
}
}
}
# Root KMS Key (managed by AWS KMS in this example)
# Keep in mind that sensitive values are provided via ENV VARS
# in this example, such as access_key and secret_key
kms "awskms" {
purpose = "root"
region = "us-east-1"
kms_key_id = "19ec80b0-dfdd-4d97-8164-c6examplekey"
endpoint = "https://vpce-0e1bb1852241f8cc6-pzi0do8n.kms.us-east-1.vpce.amazonaws.com"
}
# Recovery KMS Key
kms "awskms" {
purpose = "recovery"
region = "us-east-1"
kms_key_id = "19ec80b0-dfdd-4d97-8164-c6examplekey2"
endpoint = "https://vpce-0e1bb1852241f8cc6-pzi0do8n.kms.us-east-1.vpce.amazonaws.com"
}
# Worker-Auth KMS Key (optional, only needed if you use
# KMS authenticated workers)
kms "awskms" {
purpose = "worker-auth"
region = "us-east-1"
kms_key_id = "19ec80b0-dfdd-4d97-8164-c6examplekey3"
endpoint = "https://vpce-0e1bb1852241f8cc6-pzi0do8n.kms.us-east-1.vpce.amazonaws.com"
}
# BSR KMS Key (optional, only needed if you use the
# session recording feature)
kms "awskms" {
purpose = "bsr"
region = "us-east-1"
kms_key_id = "19ec80b0-dfdd-4d97-8164-c6examplekey4"
endpoint = "https://vpce-0e1bb1852241f8cc6-pzi0do8n.kms.us-east-1.vpce.amazonaws.com"
}
```
</CodeBlockConfig>
Refer to the list below for explanations of the parameters used in the example above:
- `disable mlock (bool: false)` - Disables the server from executing the `mlock` syscall, which prevents memory swap to the disk.
Preventing memory swap is fine for local development and testing.
However, HashiCorp does not recommend using it for production unless the systems running Boundary use encrypted swap or do not use swap at all.
Boundary only supports memory locking on UNIX-like systems that support `mlock()` syscall like Linux and FreeBSD.
On Linux, to give the Boundary executable the ability to use `mlock` syscall without running the process as root, run the following command:
`sudo setcap cap_ipc_lock=+ep $(readlink -f $(which boundary))`
If you use a Linux distribution with a modern version of systemd, you can add the following directive to the **"[Service]"** configuration section:
`LimitMEMLOCK=infinity`
- `listener` - Configures the listeners on which Boundary serves traffic (API cluster and proxy).
- `controller` - Configures the controller.
If present, `boundary server` starts a controller subprocess.
- `events` - Configures event-specific parameters.
The example events configuration above is exhaustive and writes all events to both `stderr` and a file.
This configuration may or may not work for your organization's logging solution.
- `kms` - Configures KMS blocks for [various purposes](/boundary/docs/secure/encryption/data-encryption).
Refer to the links below for configuration information for the different cloud KMS blocks:
- [AWS](/boundary/docs/configuration/kms/awskms)
- [Azure](/boundary/docs/configuration/kms/azurekeyvault)
- [GCP](/boundary/docs/configuration/kms/gcpckms)
- [OCI](/boundary/docs/configuration/kms/ocikms)
- [AliCloud](/boundary/docs/configuration/kms/alicloudkms)
- [Vault Transit](/boundary/docs/configuration/kms/transit)
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.
Initialization is a one-time operation that executes the required database migrations for the Boundary cluster to operate.
```shell-session
boundary database init -config /etc/boundary.d/controller.hcl
```
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
resources, however, are not required. You can add the following flags to skip creating these initial resources:
```shell-session
boundary database init \
-skip-auth-method-creation \
-skip-host-resources-creation \
-skip-scopes-creation \
-skip-target-creation \
-config /etc/boundary.d/controller.hcl
```
Use the following command to view the help for additional initialization options:
```shell-session
boundary database init -h
```
## Start the Boundary service
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`.
Run the following commands to start the service:
1. `sudo systemctl enable boundary`
1. `sudo systemctl start boundary`
## Authenticate and manage resources
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.
Creating an admin user allows you to configure targets within those scopes and manage them.
HashiCorp recommends that you use the [KMS recovery workflow](/boundary/docs/deploy/self-managed/initialize#log-in-with-recovery-kms) to log in to Boundary for the first time.
Refer to [Creating your first login account](/boundary/docs/deploy/self-managed/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.
## Next steps
After you configure the controller, you should:
1. [Deploy workers](/boundary/docs/deploy/self-managed/deploy-workers)
1. [Initialize Boundary](/boundary/docs/deploy/self-managed/initialize)
1. [Install the Boundary Clients](/boundary/docs/deploy/self-managed/install-clients)
website/content/docs/deploy/self-managed/deploy-workers.mdx
+278
View File
@@ -0,0 +1,278 @@
---
layout: docs
page_title: Deploy workers
description: >-
Configure Boundary workers for a self-managed deployment, including environment files and KMS keys. Set up ingress, intermediary, and egress roles for multi-hop.
---
# Deploy workers
Before you deploy workers, you should have completed the following steps:
- Installed Boundary on at least three [controller nodes](/boundary/docs/deploy/self-managed/configure-controllers).
- Prepared or have three existing network boundaries:
- Public/DMZ network
- Intermediary network
- Private network
- Prepared three virtual machines for Boundary workers, one in each network boundary with the Boundary binary installed on it.
In the following configuration files, there are common configuration components as well as some unique components depending on the role the Boundary worker performs.
There are three files, one for each worker in a unique network boundary.
Additionally, Boundary Enterprise supports a [multi-hop configuration](/boundary/docs/workers/multi-hop) in which the Boundary workers can serve one of three purposes: an ingress worker, an ingress/egress worker, or an egress worker.
## Prepare the environment files
HashiCorp recommends using either the `env://` or `file://` notation within the configuration files, to securely provide secret configuration components to the Boundary worker binaries.
The following configuration example uses `env://` to secure AWS KMS configuration items.
When you install the Boundary binary using a package manager, it includes a unit file which configures an environment file at `/etc/boundar.d/boundary.env`.
You can use this file to set the sensitive values that are used to configure the Boundary workers.
The following file is an example of how this environment file could be configured:
<CodeBlockConfig lineNumbers filename="/etc/boundary.d/boundary.env">
```shell-session
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
```
</CodeBlockConfig>
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.
## Prepare the worker KMS keys
The worker-auth storage KMS key is used by a Worker for the encrypted storage of authentication keys.
This is recommended Workers using controller-led or worker-led methods. If it is not specified, the authentication keys are not encrypted on disk.
Optionally, if you deploy KMS authentication-driven Boundary workers, an additional KMS key must be generated to authenticate the Boundary worker with the controller.
HashiCorp strongly recommends using the Key Management System (KMS) of the cloud provider where you deploy your Boundary workers.
Keep in mind that Boundary workers must have the correct level of permissions for interacting with the cloud provider's KMS.
Refer to your cloud provider's documentation, for more information.
## Create the worker configurations
After you create the requisite key or keys in the cloud provider of your choice, you can begin configuring the workers.
The following configuration examples all employ the worker-led authorization flow.
For more information on configuring KMS authentication for Boundary workers, refer to the [KMS authentication configuration documenation](/boundary/docs/workers/registration#kms-configuration).
If you use Boundary Enterprise, you can configure multiple workers to act in three different roles: ingress, intermediary, and egress.
For Community Edition, workers only serve one role, acting as both the point of ingress and egress.
Select your Boundary edition, and complete the following steps to configure workers.
<Tabs>
<Tab heading="Enterprise">
For Boundary Enterprise, you can configure ingress, intermediary, and egress workers to take advantage of [multi-hop worker capabilities](/boundary/docs/workers#multi-hop-sessions).
Note that "ingress," "intermediary," and "egress" are general ways to describe how the respective worker interacts with resources.
A worker can serve more than one of those roles at a time.
Refer to [Multi-hop sessions](/boundary/docs/workers/multi-hop) for more information.
Complete the steps below to configure workers for Boundary Enterprise.
### Ingress worker configuration
@include '/workers/ingress-worker-config.mdx'
### Intermediate worker configuration
@include '/workers/intermediate-worker-config.mdx'
### Egress worker configuration
@include '/workers/egress-worker-config.mdx'
</Tab>
<Tab heading="Community Edition">
For the Community Edition of Boundary, you must configure a worker server that communicates with the controller and is responsible for storage-related tasks.
Boundary Community Edition only supports egress workers. To configure workers for multi-hop sessions, check the Boundary Enterprise configuration.
Complete the following steps to configure the worker.
### Worker configuration
@include '/workers/single-worker-config.mdx'
</Tab>
</Tabs>
## Start the Boundary service
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 worker nodes using `systemd`.
Run the following commands to start the service:
1. `sudo systemctl enable boundary`
1. `sudo systemctl start boundary`
## Adopt the workers (optional)
If you use the workers as outlined above, you must adopt the Boundary workers.
Complete the following steps to adopt the workers:
<Tabs>
<Tab heading="Admin UI">
Complete the following steps to adopt the worker using the UI:
1. Log in to Boundary as the admin user.
1. Select **Workers** in the navigation pane.
1. Click **New**.
1. (Optional) You can use the workers page to construct the contents of the `worker.hcl` file, if you did not [create the configuration file](/boundary/docs/deploy/self-managed/deploy-workers#create-the-worker-configurations) as part of the installation process above.
Provide the following details, and Boundary constructs the worker configuration file for you:
- Boundary Cluster ID
- Worker Public Address
- Config file path
- Worker Tags
1. Scroll to the bottom of the **New Worker** page, and paste the **Worker Auth Registration Request** key.
Boundary provides you with the **Worker Auth Registration Request** key in the CLI output when you start the worker.
You can also locate this value in the `auth_request_token` file.
1. Click **Register Worker**.
1. Click **Done**.
The new worker appears on the **Workers** page.
1. Repeat the registration process for any other workers, such as the intermediate and egress workers.
</Tab>
<Tab heading="CLI">
Complete the following steps to adopt the worker using the CLI:
1. Use the following command to ensure that the `BOUNDARY_ADDR` is set as an environment variable:
```hcl
$ export BOUNDARY_ADDR="https://c3a7a20a-f663-40f3-a8e3-1b2f69b3625.boundary.hashicorp.cloud"
```
1. Log into the CLI as the admin user, providing the Auth Method ID, admin login name, and admin password when prompted.
```hcl
$ boundary authenticate password \
-auth-method-id=ampw_KfLAjMS2CG \
-login-name=admin
```
Example:
<CodeBlockConfig hideClipboard>
```hcl
$ boundary authenticate password \
-auth-method-id=ampw_KfLAjMS2CG \
-login-name=admin
Please enter the password (it will be hidden):
Authentication information:
Account ID: acctpw_r6crEm0FgM
Auth Method ID: ampw_KfLAjMS2CG
Expiration Time: Mon, 27 Jun 2022 22:03:28 MDT
User ID: u_ysJd0LXX9T
The token was successfully stored in the chosen keyring and is not displayed here.
```
</CodeBlockConfig>
1. Next, use the following command to export the **Worker Auth Request Token** value as an environment variable:
```shell-session
$ export WORKER_TOKEN=<Worker Auth Registration Request Value>
```
Boundary provides you with the **Worker Auth Registration Request** key in the CLI output when you start the worker.
You can also locate this value in the `auth_request_token` file.
The token is used to issue a create worker request that authorizes the worker to Boundary and makes it available.
Currently worker creation is only supported for workers with an authorization token (worker-led and controller-led).
1. Create a new worker using the worker-led registration method with the following command:
```shell-session
$ boundary workers create worker-led -worker-generated-auth-token=$WORKER_TOKEN
Worker information:
Active Connection Count: 0
Created Time: Fri, 03 Jan 2025 13:52:04 MST
ID: w_zLGjAbYx1h
Local Storage State: unknown
Type: pki
Updated Time: Fri, 03 Jan 2025 13:52:04 MST
Version: 1
Scope:
ID: global
Name: global
Type: global
Authorized Actions:
no-op
read
update
delete
add-worker-tags
set-worker-tags
remove-worker-tags
```
Confirm the worker registration and view its details by executing the following command and supplying the new worker's id:
```shell-session
$ boundary workers read -id w_zLGjAbYx1h
Worker information:
Active Connection Count: 0
Address: 127.0.0.1:9202
Created Time: Fri, 03 Jan 2025 13:52:04 MST
ID: w_zLGjAbYx1h
Last Status Time: 2025-01-03 20:58:41.346537 +0000 UTC
Local Storage State: not configured
Release Version: Boundary v0.18.1+ent
Type: pki
Updated Time: Fri, 03 Jan 2025 13:58:41 MST
Version: 1
Scope:
ID: global
Name: global
Type: global
Tags:
Configuration:
type: ["worker1" "upstream"]
Canonical:
type: ["upstream" "worker1"]
Authorized Actions:
add-worker-tags
set-worker-tags
remove-worker-tags
no-op
read
update
delete
```
1. Repeat the registration process for any other workers, such as the intermediate and egress workers.
</Tab>
</Tabs>
## Next steps
After you configure workers, you should:
1. [Initialize Boundary](/boundary/docs/deploy/self-managed/initialize)
1. [Install the Boundary Clients](/boundary/docs/deploy/self-managed/install-clients)
website/content/docs/deploy/self-managed/index.mdx
+51
View File
@@ -0,0 +1,51 @@
---
layout: docs
page_title: Deploy Boundary in a self-managed environment
description: >-
Discover resources for deploying a self-managed version of Boundary Enterprise or Boundary Community Edition.
---
# Deploy Boundary in a self-managed environment
To deploy a self-managed Boundary environment you should:
1. Install the Boundary binary
1. Deploy and configure Boundary controllers and workers
1. Install end-user clients
This guide outlines the required steps to manually install and configure a
single self-managed HashiCorp Boundary cluster as defined in the Recommended
architecture topic.
It assumes you install Boundary on virtual machines (VMs) or bare-metal servers
running a Debian or Red Hat-based Linux distribution.
To deploy HCP Boundary instead, refer to the [Deploy and log in](/boundary/docs/hcp/get-started/deploy-and-login) in the HCP Boundary Get started documentation.
This document includes general guidance as well as specific recommendations for
popular cloud infrastructure platforms. These recommendations have also been
encoded into official Terraform reference architectures for
[AWS](https://github.com/hashicorp/boundary-reference-architecture/tree/main/deployment/aws),
[Azure](https://github.com/hashicorp/boundary-reference-architecture/tree/main/deployment/azure),
and
[GCP](https://github.com/hashicorp/boundary-reference-architecture/tree/main/deployment/gcp).
## More information
Before you begin, you may want to review the following information about Boundary's architecture and system requirements:
- [System requirements](/boundary/docs/architecture/system-requirements)
- [Recommended architecture](/boundary/docs/architecture/recommended-architecture)
- [Fault tolerance](/boundary/docs/architecture/fault-tolerance)
- [High availability](/boundary/docs/architecture/high-availability)
## Next steps
Refer to the following topics to deploy your self-managed environment:
1. [Install Boundary](/boundary/docs/deploy/self-managed/install)
1. [Configure controllers](/boundary/docs/deploy/self-managed/configure-controllers)
1. [Deploy workers](/boundary/docs/deploy/self-managed/deploy-workers)
1. [Initialize Boundary](/boundary/docs/deploy/self-managed/initialize)
1. [Install Boundary clients](/boundary/docs/deploy/self-managed/install-clients)
To configure Boundary resources using Terraform, refer to [Terraform patterns](/boundary/docs/deploy/terraform-patterns).
website/content/docs/deploy/self-managed/initialize.mdx
+468
View File
@@ -0,0 +1,468 @@
---
layout: docs
page_title: Initialize Boundary
description: >-
Initialize new Boundary self-managed installations. Log in with the recovery KMS to create initial scope, auth method, login account, user, and role resources.
---
# Initialize Boundary
This document describes how to access Boundary for the first time and create the necessary resources to log in as a
user.
You can also initialize and manage Boundary using Terraform. Refer to the [Terraform patterns](/boundary/docs/deploy/terraform-patterns) page to learn more.
## Requirements
Before you initialize Boundary, you should have [initialized a database](/boundary/docs/deploy/self-managed/configure-controllers#initialize-the-database).
## Log in with recovery KMS
To access a new Boundary instance for the first time, you must use the recovery KMS defined in the
controller configuration file. The following example represents a configuration file that uses hard-coded AEAD keys:
<Note>
In a production environment, HashiCorp recommends that you use a cloud provider's KMS such as [AWS KMS](/boundary/docs/configuration/kms/awskms)
to manage the keys Boundary uses to encrypt sensitive information.
</Note>
```hcl
<truncated>
kms "aead" {
purpose = "root"
aead_type = "aes-gcm"
key = "sP1fnF5Xz85RrXyELHFeZg9Ad2qt4Z4bgNHVGtD6ung="
key_id = "global_root"
}
kms "aead" {
purpose = "worker-auth"
aead_type = "aes-gcm"
key = "8fZBjCUfN0TzjEGLQldGY4+iE9AkOvCfjh7+p0GtRBQ="
key_id = "global_worker-auth"
}
kms "aead" {
purpose = "recovery"
aead_type = "aes-gcm"
key = "8fZBjCUfN0TzjEGLQldGY4+iE9AkOvCfjh7+p0GtRBQ="
key_id = "global_recovery"
}
<truncated>
```
The KMS with the `recovery` purpose is used to "recover" Boundary, allowing you to authenticate to Boundary and manage
it as a super user. It also allows you to authenticate from the CLI or from Terraform to manage Boundary
without any generated resources.
To authenticate to Boundary using the recovery KMS workflow:
<Tabs>
<Tab heading="CLI">
To use the recovery workflow on the CLI, you must pass the `-recovery-config <path_to_kms_recovery_config>` flag or set the environment
variable for `BOUNDARY_RECOVERY_CONFIG` for every command ran. Authentication takes place for every command
ran when using the recovery workflow. The `boundary authenticate` command does not apply when you use the recovery KMS.
```shell-session
$ cat << EOF > /tmp/recovery.hcl
kms "aead" {
purpose = "recovery"
aead_type = "aes-gcm"
key = "8fZBjCUfN0TzjEGLQldGY4+iE9AkOvCfjh7+p0GtRBQ="
key_id = "global_recovery"
}
EOF
# Example command
$ boundary users create <truncated> -recovery-config /tmp/recovery.hcl
...
```
</Tab>
<Tab heading="Terraform">
To configure your provider to use the recovery KMS workflow, provide the KMS block as the value for
`recovery_kms_hcl`:
```hcl
provider "boundary" {
addr = "https://boundary.mycorp.com:9200"
recovery_kms_hcl = <<EOT
kms "aead" {
purpose = "recovery"
aead_type = "aes-gcm"
key = "8fZBjCUfN0TzjEGLQldGY4+iE9AkOvCfjh7+p0GtRBQ="
key_id = "global_recovery"
}
EOT
}
```
</Tab>
</Tabs>
## Create your first login account
This section covers how to configure your first auth method, user, account, and role to log in to Boundary without
the recovery KMS workflow. In this example, we are going to make an admin user for the global and project level
scopes we create. This will allow our user to configure targets within those scopes and manage them.
### Create org and project scopes
First, create an org and project scope and skip creating an administrator and admin role for each scope. We are going to
specify a role for managing these scopes by selected users in a later step.
<Tabs>
<Tab heading="CLI">
```shell-session
$ boundary scopes create -name 'org' -scope-id 'global' \
-recovery-config /tmp/recovery.hcl \
-skip-admin-role-creation \
-skip-default-role-creation
<truncated>
$ boundary scopes create -name 'project' -scope-id <org_scope_id_from_last_step> \
-recovery-config /tmp/recovery.hcl \
-skip-admin-role-creation \
-skip-default-role-creation
<truncated>
```
</Tab>
<Tab heading="Terraform">
```hcl
resource "boundary_scope" "org" {
scope_id = "global"
name = "organization"
description = "Organization scope"
auto_create_admin_role = false
auto_create_default_role = false
}
resource "boundary_scope" "project" {
name = "project"
description = "My first project"
scope_id = boundary_scope.org.id
auto_create_admin_role = false
auto_create_default_role = false
}
```
</Tab>
</Tabs>
### Create an auth method
Create an auth method in the organization scope.
<Tabs>
<Tab heading="CLI">
```shell-session
$ boundary auth-methods create password \
-recovery-config /tmp/recovery.hcl \
-scope-id <org_scope_id> \
-name 'my_method' \
-description 'My password auth method'
```
</Tab>
<Tab heading="Terraform">
```hcl
resource "boundary_auth_method" "password" {
name = "my_password_auth_method"
description = "Password auth method"
type = "password"
scope_id = boundary_scope.org.id
}
```
</Tab>
</Tabs>
### Create a login account
Create a login account for the auth method.
<Tabs>
<Tab heading="CLI">
```shell-session
$ boundary accounts create password \
-recovery-config /tmp/recovery.hcl \
-login-name "myuser" \
-auth-method-id <auth_method_id_from_last_step>
```
</Tab>
<Tab heading="Terraform">
```hcl
resource "boundary_account" "myuser" {
name = "myuser"
description = "User account for my user"
type = "password"
login_name = "myuser"
password = "foofoofoo"
auth_method_id = boundary_auth_method.password.id
}
```
</Tab>
</Tabs>
### Create a user
Create a user and associate the user with the login account created in the previous step.
This user will also be the principal in the role we create in the following step.
<Tabs>
<Tab heading="CLI">
```shell-session
$ boundary users create -scope-id <org_scope_id> \
-recovery-config /tmp/recovery.hcl \
-name "myuser" \
-description "My user!"
$ boundary users add-accounts \
-recovery-config /tmp/recovery.hcl \
-id <myuser_user_id> \
-account <myuser_account_id>
```
</Tab>
<Tab heading="Terraform">
```hcl
resource "boundary_user" "myuser" {
name = "myuser"
description = "My user!"
account_ids = [boundary_account.myuser.id]
scope_id = boundary_scope.org.id
}
```
</Tab>
</Tabs>
### Create roles to manage scopes
The following section describes the four baseline roles you must create to manage resources within the org and project
scopes that you created. These roles are similar to the roles Boundary automatically created for you if you did not skip generation using the `-skip-initial-login-role-creation` flag when you ran `boundary database init`. Declaring roles explicitly
allows you to manage them independently and fully within Terraform or via the CLI. In doing so, you can precisely define their access.
The following example creates 4 roles:
1. To allow anonymous (unauthenticated) users the ability to list scopes and auth methods in the global scope.
1. To allow anonymous (unauthenticated) users the ability to list scopes and auth methods in the organization scope.
1. To allow `myuser` user administration grants at the org scope.
1. To allow `myuser` user administration grants at the project scope.
#### Anonymous listing role for global scope
<Tabs>
<Tab heading="CLI">
Assumes recovery key export from above steps is still set:
```shell-session
# Create global anonymous listing role
$ boundary roles create -name 'global_anon_listing' \
-recovery-config /tmp/recovery.hcl \
-scope-id 'global'
$ boundary roles add-grants -id <global_anon_listing_id> \
-recovery-config /tmp/recovery.hcl \
-grant 'ids=*;type=auth-method;actions=list,authenticate' \
-grant 'ids=*;type=scope;actions=list,no-op' \
-grant 'ids={{.Account.Id}};actions=read,change-password'
$ boundary roles add-principals -id <global_anon_listing_id> \
-recovery-config /tmp/recovery.hcl \
-principal 'u_anon'
```
</Tab>
<Tab heading="Terraform">
```hcl
resource "boundary_role" "global_anon_listing" {
scope_id = "global"
grant_strings = [
"ids=*;type=auth-method;actions=list,authenticate",
"ids=*;type=scope;actions=list,no-op",
"ids={{.Account.Id}};actions=read,change-password"
]
principal_ids = ["u_anon"]
}
```
</Tab>
</Tabs>
#### Anonymous listing role for org scope
<Tabs>
<Tab heading="CLI">
Assumes recovery key export from above steps is still set:
```shell-session
$ boundary roles create -name 'org_anon_listing' \
-recovery-config /tmp/recovery.hcl \
-scope-id <org_scope_id>
$ boundary roles add-grants -id <org_anon_listing_id> \
-recovery-config /tmp/recovery.hcl \
-grant 'ids=*;type=auth-method;actions=list,authenticate' \
-grant 'type=scope;actions=list' \
-grant 'ids={{.Account.Id}};actions=read,change-password'
$ boundary roles add-principals -id <org_anon_listing_id> \
-recovery-config /tmp/recovery.hcl \
-principal 'u_anon'
```
</Tab>
<Tab heading="Terraform">
```hcl
resource "boundary_role" "org_anon_listing" {
scope_id = boundary_scope.org.id
grant_strings = [
"ids=*;type=auth-method;actions=list,authenticate",
"type=scope;actions=list",
"ids={{.Account.Id}};actions=read,change-password"
]
principal_ids = ["u_anon"]
}
```
</Tab>
</Tabs>
#### Org admin role for myuser
<Tabs>
<Tab heading="CLI">
Assumes recovery key export from above steps is still set:
```shell-session
$ boundary roles create -name 'org_admin' \
-recovery-config /tmp/recovery.hcl \
-scope-id 'global'
$ boundary roles set-grant-scopes \
-id <org_admin_id> \
-grant-scope-id <org_scope_id>
$ boundary roles add-grants -id <org_admin_id> \
-recovery-config /tmp/recovery.hcl \
-grant 'ids=*;type=*;actions=*'
$ boundary roles add-principals -id <org_admin_id> \
-recovery-config /tmp/recovery.hcl \
-principal <myuser_user_id>
```
</Tab>
<Tab heading="Terraform">
```hcl
resource "boundary_role" "org_admin" {
scope_id = "global"
grant_scope_ids = [boundary_scope.org.id]
grant_strings = [
"ids=*;type=*;actions=*"
]
principal_ids = [boundary_user.myuser.id]
}
```
</Tab>
</Tabs>
#### Project admin for myuser
<Tabs>
<Tab heading="CLI">
Assumes recovery key export from above steps is still set:
```shell-session
$ boundary roles create -name 'project_admin' \
-recovery-config /tmp/recovery.hcl \
-scope-id <org_scope_id> \
-grant-scope-id <project_scope_id>
$ boundary roles add-grants -id <project_admin_id> \
-recovery-config /tmp/recovery.hcl \
-grant 'ids=*;type=*;actions=*'
$ boundary roles add-principals -id <project_admin_id> \
-recovery-config /tmp/recovery.hcl \
-principal <myuser_user_id>
```
</Tab>
<Tab heading="Terraform">
```hcl
resource "boundary_role" "project_admin" {
scope_id = boundary_scope.org.id
grant_scope_ids = [boundary_scope.project.id]
grant_strings = [
"ids=*;type=*;actions=*"
]
principal_ids = [boundary_user.myuser.id]
}
```
</Tab>
</Tabs>
### Log in as your new user
```shell-session
boundary authenticate password \
-auth-method-id <auth_method_id>
```
## Next steps
After you initialize Boundary, you should [Install the Boundary Clients](/boundary/docs/deploy/self-managed/install-clients).
website/content/docs/deploy/self-managed/install-clients.mdx
+59
View File
@@ -0,0 +1,59 @@
---
layout: docs
page_title: Install Boundary clients
description: >-
Install the Boundary CLI, Boundary Desktop Client app, or Boundary installer for Boundary Enterprise or Community Edition on Windows, MacOS, or Linux.
---
# Install Boundary clients
Boundary end users access infrastructure targets using the Boundary Desktop Client app or the Boundary CLI. Enterprise or HCP Boundary users can use transparent sessions to proxy traffic through the Boundary Client Agent <sup>HCP/ENT</sup>.
This guide outlines the required steps to manually install and configure a Boundary client depending on which distribution of Boundary end users access.
To learn about installing the Boundary binary when you deploy Boundary controllers or workers, refer to the [Install Boundary](/boundary/docs/deploy/self-managed/install) page.
Select your Boundary distribution, and complete the steps to install the
correct clients:
<Tabs>
<Tab heading="Enterprise">
@include 'alerts/enterprise-only.mdx'
The Boundary installer bundles together the following components:
- Boundary binary (CLI)
- Boundary Desktop Client app
- Boundary Client Agent <sup>HCP/ENT</sup>
Download the appropriate Boundary installer for your Windows, MacOS, or Linux environment from the [Install Boundary](/boundary/install#installer) downloads page or the [releases](https://releases.hashicorp.com/boundary-installer) page. You can also download the components individually, but compatibility is not guaranteed. Refer to the [Supported versions policy](/boundary/docs/enterprise/supported-versions#control-plane-and-client-cli-compatibility) to learn more.
<Warning>
Before you launch the Boundary installer, ensure that you have uninstalled all previous versions of the Boundary binary and Boundary Desktop Client app.
</Warning>
To learn more about installing the Boundary CLI and Boundary Desktop Client app, refer to the [Get started with HCP Boundary](/boundary/tutorials/get-started-hcp) tutorials.
</Tab>
<Tab heading="Community Edition">
We recommend the following components for end users:
- Boundary binary (CLI)
- Boundary Desktop Client app
Download these components for your Windows, MacOS, or Linux environment from the [Install Boundary](/boundary/install) downloads page or the [HashiCorp releases](https://releases.hashicorp.com/) page.
<Warning>
Client compatibility is not guaranteed. You should always ensure that your client is compatible with the version of the Boundary control plane you connect to. Refer to the [Supported versions policy](/boundary/docs/enterprise/supported-versions#control-plane-and-client-cli-compatibility) to learn more.
</Warning>
To learn more about installing the Boundary CLI and Boundary Desktop Client app, refer to the [Get started with self-managed Boundary](/boundary/tutorials/get-started-community) tutorials.
</Tab>
</Tabs>
website/content/docs/deploy/self-managed/install.mdx
+194
View File
@@ -0,0 +1,194 @@
---
layout: docs
page_title: Install Boundary
description: >-
Deploy a self-managed version of Boundary Enterprise or Community Edition on Ubuntu/Debian, CentOS/RHEL, or Amazon Linux by installing the binary file.
---
# Install Boundary
Pre-built Boundary packages are available from the [HashiCorp Linux
Repository](https://www.hashicorp.com/blog/announcing-the-hashicorp-linux-repository).
In addition to installing the Boundary binary, the official package also
provides a systemd service unit, and a local `boundary` user account under which
the service runs.
<Note>
You must complete the following steps for each Boundary controller and worker
node that you want to deploy. The binary operates as either a worker or
controller, depending on the configuration that you generate for the
Boundary binary.
</Note>
The steps vary by Linux distribution.
Select your distribution of Boundary, and complete the steps to install the
binary:
<Tabs>
<Tab heading="Enterprise">
<Tabs>
<Tab heading="Ubuntu/Debian">
1. Use the following command to add the HashiCorp GPC key as a trusted
package-signing key:
```shell-session
$ curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
```
1. Add the official HashiCorp Linux repository:
```shell-session
$ echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
```
1. Update the package index:
```shell-session
$ sudo apt update
```
1. Install Boundary Enterprise:
```shell-session
$ sudo apt install boundary-enterprise
```
</Tab>
<Tab heading="CentOS/RHEL">
1. Use the following command to install `yum-config-manager` to manage your
repositories:
```shell-session
$ sudo yum install -y yum-utils
```
2. Add the official HashiCorp Linux repository:
```shell-session
$ sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
```
3. Install Boundary Enterprise:
```shell-session
$ sudo yum -y install boundary-enterprise
```
</Tab>
<Tab heading="Amazon Linux">
1. Use the following command to install `yum-config-manager` to manage your
repositories:
```shell-session
$ sudo yum install -y yum-utils shadow-utils
```
2. Add the official HashiCorp Linux repository:
```shell-session
$ sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo
```
3. Install Boundary Enterprise:
```shell-session
$ sudo yum -y install boundary-enterprise
```
</Tab>
</Tabs>
</Tab>
<Tab heading="Community Edition">
<Tabs>
<Tab heading="Ubuntu/Debian">
1. Use the following command to add the HashiCorp GPC key as a trusted
package-signing key:
```shell-session
$ curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
```
1. Add the official HashiCorp Linux repository:
```shell-session
$ echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
```
1. Update the package index:
```shell-session
$ sudo apt update
```
1. Install Boundary Community Edition:
```shell-session
$ sudo apt install boundary
```
</Tab>
<Tab heading="CentOS/RHEL">
1. Use the following command to install `yum-config-manager` to manage your
repositories:
```shell-session
$ sudo yum install -y yum-utils
```
2. Add the official HashiCorp Linux repository:
```shell-session
$ sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
```
3. Install Boundary Community Edition:
```shell-session
$ sudo yum -y install boundary
```
</Tab>
<Tab heading="Amazon Linux">
1. Use the following command to install `yum-config-manager` to manage your
repositories:
```shell-session
$ sudo yum install -y yum-utils shadow-utils
```
2. Add the official HashiCorp Linux repository:
```shell-session
$ sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo
```
3. Install Boundary Community Edition:
```shell-session
$ sudo yum -y install boundary
```
</Tab>
</Tabs>
</Tab>
</Tabs>
You should install the binary on the controller and worker instances you configure to run in your Boundary environments.
## Next steps
After you install the binary, you should:
1. [Configure controllers](/boundary/docs/deploy/self-managed/configure-controllers)
1. [Deploy workers](/boundary/docs/deploy/self-managed/deploy-workers)
1. [Initialize Boundary](/boundary/docs/deploy/self-managed/initialize)
1. [Install the Boundary Clients](/boundary/docs/deploy/self-managed/install-clients)
website/content/docs/deploy/self-managed/systemd.mdx
+90
View File
@@ -0,0 +1,90 @@
---
layout: docs
page_title: systemd Installation
description: |-
How to install Boundary under systemd on Linux
---
# Install Boundary under systemd
This section covers how to install Boundary under the [systemd](https://systemd.io/) init system on modern Linux distributions. In this section, we'll cover an example of breaking out the controller and worker servers onto separate instances, though you can opt to run both on a single server.
## Filesystem configuration
`TYPE` below can be either `worker` or `controller` if you want to run them independently, e.g. for high availability. If you want to run combined nodes, modify as desired.
1. `/etc/boundary.d/boundary-${TYPE}.hcl`: Configuration file for the boundary service.
2. `/usr/local/bin/boundary`: The Boundary binary, which can be built from the [source](https://github.com/hashicorp/boundary) or downloaded from our [release page](/boundary/downloads).
3. `/etc/systemd/system/boundary-${TYPE}.service`: Systemd unit file for the Boundary service.
## User and group configuration
We recommend running Boundary as a non-root user and using this user to manage the Boundary process running under systemd. The example init files here do exactly that. Our example install script below creates a user and group on Ubuntu or Debian-like systems.
## systemd unit file
```
[Unit]
Description=${NAME} ${TYPE}
[Service]
ExecStart=/usr/local/bin/${NAME} server -config /etc/${NAME}-${TYPE}.hcl
User=boundary
Group=boundary
LimitMEMLOCK=infinity
Capabilities=CAP_IPC_LOCK+ep
CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK
[Install]
WantedBy=multi-user.target
```
## systemd all-in-one installation script
Here's a simple install script that creates the `boundary` group and user, installs the
systemd unit file, and enables it at startup:
```
#!/bin/bash
# Installs the boundary as a service for systemd on linux
# Usage: ./install.sh <worker|controller>
TYPE=$1
NAME=boundary
sudo cat << EOF > /etc/systemd/system/${NAME}-${TYPE}.service
[Unit]
Description=${NAME} ${TYPE}
[Service]
ExecStart=/usr/local/bin/${NAME} server -config /etc/${NAME}-${TYPE}.hcl
User=boundary
Group=boundary
LimitMEMLOCK=infinity
Capabilities=CAP_IPC_LOCK+ep
CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK
[Install]
WantedBy=multi-user.target
EOF
# Add the boundary system user and group to ensure we have a no-login
# user capable of owning and running Boundary
sudo adduser --system --group boundary || true
sudo chown boundary:boundary /etc/${NAME}-${TYPE}.hcl
sudo chown boundary:boundary /usr/local/bin/boundary
# Make sure to initialize the DB before starting the service. This will result in
# a database already initialized warning if another controller or worker has done this
# already, making it a lazy, best effort initialization
if [ "${TYPE}" = "controller" ]; then
sudo /usr/local/bin/boundary database init -config /etc/${NAME}-${TYPE}.hcl || true
fi
sudo chmod 664 /etc/systemd/system/${NAME}-${TYPE}.service
sudo systemctl daemon-reload
sudo systemctl enable ${NAME}-${TYPE}
sudo systemctl start ${NAME}-${TYPE}
```