Manage workers

disable_mlock = true listener "tcp" {  address = "127.0.0.1:9204"  purpose = "proxy"} worker {  auth_storage_path = "/home/myusername/boundary/worker1"  initial_upstreams = ["127.0.0.1"]  controller_generated_activation_token = "<Controller-Generated Activation Token Value>"  tags {    type = ["worker", "local"]  }}

Update the <Controller-Generated Activation Token Value> on line 3 with the token value copied from the boundary workers create controller-led command output.

Update the auth_storage_path** to match the full path to the ~/boundary/worker1 directory, such as /home/myusername/boundary/worker1.

Notice the listener "tcp" address is set to "127.0.0.1:9204". Because Boundary is running in dev mode, a pre-configured worker is already listening on port 9202. To avoid conflicts, the new worker listens on 9204. In a non-dev deployment, the worker would usually listen on port 9202.

Also notice the worker initial_upstreams is set to 127.0.0.1. In a non-dev deployment, this address would resolve to an upstream controller.

disable_mlock = true listener "tcp" {  address = "127.0.0.1:9204"  purpose = "proxy"} worker {  auth_storage_path = "/Users/myusername/boundary/worker1"  initial_upstreams = ["127.0.0.1"]  controller_generated_activation_token = "<Controller-Generated Activation Token Value>"  tags {    type = ["worker", "local"]  }}

Update the <Controller-Generated Activation Token Value> on line 3 with the token value copied from the boundary workers create controller-led command output.

Update the auth_storage_path** to match the full path to the ~/boundary/worker1 directory, such as /Users/myusername/boundary/worker1.

Notice the listener "tcp" address is set to "127.0.0.1:9204". Because Boundary is running in dev mode, a pre-configured worker is already listening on port 9202. To avoid conflicts, the new worker listens on 9204. In a non-dev deployment, the worker would usually listen on port 9202.

Also notice the worker initial_upstreams is set to 127.0.0.1. In a non-dev deployment, this address would resolve to an upstream controller.

disable_mlock = true listener "tcp" {  address = "127.0.0.1:9204"  purpose = "proxy"} worker {  auth_storage_path = "C:/Users/myusername/boundary/worker1"  initial_upstreams = ["127.0.0.1"]  controller_generated_activation_token = "<Controller-Generated Activation Token Value>"  tags {    type = ["worker", "local"]  }}

Update the <Controller-Generated Activation Token Value> on line 3 with the token value copied from the boundary workers create controller-led command output.

Update the auth_storage_path** to match the full path to the ~/boundary/worker1 directory, such as C:/Users/myusername/boundary/worker1.

Notice the listener "tcp" address is set to "127.0.0.1:9204". Because Boundary is running in dev mode, a pre-configured worker is already listening on port 9202. To avoid conflicts, the new worker listens on 9204. In a non-dev deployment, the worker would usually listen on port 9202.

Also notice the worker initial_upstreams is set to 127.0.0.1. In a non-dev deployment, this address would resolve to an upstream controller.

disable_mlock = true listener "tcp" {  address = "127.0.0.1:9204"  purpose = "proxy"} worker {  auth_storage_path = "/home/myusername/boundary/worker1"  initial_upstreams = ["127.0.0.1"]  tags {    type = ["worker", "local"]  }}

Update the auth_storage_path** to match the full path to the ~/boundary/worker1 directory, such as /home/myusername/boundary/worker1.

Notice the listener "tcp" address is set to "127.0.0.1:9204". Because Boundary is running in dev mode, a pre-configured worker is already listening on port 9202. To avoid conflicts, the new worker listens on 9204. In a non-dev deployment, the worker would usually listen on port 9202.

Also notice the worker initial_upstreams is set to 127.0.0.1. In a non-dev deployment, this address would resolve to an upstream controller.

disable_mlock = true listener "tcp" {  address = "127.0.0.1:9204"  purpose = "proxy"} worker {  auth_storage_path = "/Users/myusername/boundary/worker1"  initial_upstreams = ["127.0.0.1"]  tags {    type = ["worker", "local"]  }}

Update the auth_storage_path** to match the full path to the ~/boundary/worker1 directory, such as /Users/myusername/boundary/worker1.

Notice the listener "tcp" address is set to "127.0.0.1:9204". Because Boundary is running in dev mode, a pre-configured worker is already listening on port 9202. To avoid conflicts, the new worker listens on 9204. In a non-dev deployment, the worker would usually listen on port 9202.

Also notice the worker initial_upstreams is set to 127.0.0.1. In a non-dev deployment, this address would resolve to an upstream controller.

disable_mlock = true listener "tcp" {  address = "127.0.0.1:9204"  purpose = "proxy"} worker {  auth_storage_path = "C:\Users\myusername\boundary\worker1"  initial_upstreams = ["127.0.0.1"]  tags {    type = ["worker", "local"]  }}

Update the auth_storage_path** to match the full path to the ~/boundary/worker1 directory, such as C:\Users\myusername\boundary\worker1.

Notice the listener "tcp" address is set to "127.0.0.1:9204". Because Boundary is running in dev mode, a pre-configured worker is already listening on port 9202. To avoid conflicts, the new worker listens on 9204. In a non-dev deployment, the worker would usually listen on port 9202.

Also notice the worker initial_upstreams is set to 127.0.0.1. In a non-dev deployment, this address would resolve to an upstream controller.

Open a new terminal session.

Log into the CLI as the admin user, providing the Auth Method ID, admin login name, and admin password password when prompted.

$ boundary authenticate password -auth-method-id ampw_1234567890 -login-name adminPlease enter the password (it will be hidden): Authentication information:  Account ID:      acctpw_1234567890  Auth Method ID:  ampw_1234567890  Expiration Time: Thu, 19 Jan 2023 15:37:46 MST  User ID:         u_1234567890 The token was successfully stored in the chosen keyring and is not displayed here.

Next, export the Worker Auth Request Token value as an environment variable.

$ export WORKER_TOKEN=<Worker Auth Registration Request Value>

The token is used to issue a create worker request that will authorize the worker to Boundary and make it available.

Create a new worker:

$ boundary workers create worker-led -worker-generated-auth-token=$WORKER_TOKEN Worker information:  Active Connection Count:   0  Created Time:              Mon, 20 Jun 2022 22:17:04 MDT  ID:                        w_mAoEKay9vV  Type:                      pki  Updated Time:              Mon, 20 Jun 2022 22:17:04 MDT  Version:                   1   Scope:    ID:                      global    Name:                    global    Type:                    global   Authorized Actions:    no-op    read    update    delete

These fields are available on the boundary worker resource:

• Id: The read-only ID for this worker.
• Created time: A timestamp indicating when the worker was created.
• Last status time: A timestamp indicating when the worker last sent data to a controller
• Updated time: A timestamp indicating when this worker resource was last updated
• Version: A read-only field indicating the version number for this resource
• Active connection count: A read only field indicating the number of active session connections this worker is currently proxying.
• Scope: Indicates the scope for this resource
• Worker-Provided Configuration: Lists the values set in the worker’s configuration file
• Addresses: Lists the addresses Boundary uses when handling an authorize session request. This value will never be empty and is set within the worker config file form the following values in decreasing priority:
  • The value set in the public_address field in the worker stanza, if present.
  • The value set in the address field of the listener stanza with the "proxy" purpose, if present.
• Tags: Lists the tags set in the worker configuration file and canonical tags.

Authenticate to the Boundary Admin Console UI as the admin user.

1. Log in to the Admin Console Web UI, running at http://127.0.0.1:9200 in dev mode.

2. Enter the admin username and password and click Authenticate.

Once logged in, navigate to the Workers page.

Notice that only a single worker is listed, created automatically by boundary dev.

Click New.

The new workers page can be used to construct the contents of the worker.hcl file.

Do not fill in any of the worker fields.

Providing the following details will construct the worker config file contents for you:

• Worker Public Address
• Config file path
• Initial Upstreams
• Worker Tags

The instructions on this page provide details for constructing the worker config file and deploying the worker. This page can serve as a guide for setting up any new workers in the future.

Because the worker has already been deployed, only the Worker Auth Registration Request key needs to be provided on this page.

Scroll down to the bottom of the New Worker page and paste the Worker Auth Registration Request key you copied earlier.

Click Register Worker.

Click Done and notice the new worker on the Workers page.