Boundary Interactive Sandboxes

Setup the sandbox

If you haven't configured the sandbox workers and run Terraform yet, follow the steps below to get set up.

Start the workers

Execute the following scripts in the setup-workers directory:

$ source ./setup-workers/start-workers.sh && source .setup-workers/register-workers.sh

Note: use the command above to execute the scripts. The source command will retain the environment variables in your current session.

The script will prompt you to enter the following environment variables:

• BOUNDARY_ADDR
• BOUNDARY_ADMIN_USERNAME
• BOUNDARY_ADMIN_PASSWORD

NOTE: This sandbox is designed to manage resources in your HCP Boundary account. You must provide a username with admin-level access to HCP Boundary so Terraform can manage scopes to create the resources for the sandbox. For using the sandbox, we recommend providing credentials for an HCP Boundary cluster within a dev or test HCP org.

Set up Boundary

After the workers are started and registered to HCP Boundary, you can set up the Boundary hosts, targets, credentials, and other resources using Terraform:

$ cd ~/terraform/ && ./configure-boundary.sh

The script will set up all the resources in the terraform/ directory, including the demo targets and credential libraries. After setting up Boundary, you can connect to targets using the CLI or the Boundary Desktop Client in the Workstation Desktop tab.

What is a Boundary target?

Targets are a Boundary resource that represent a networked service or host that a user can connect to. Targets provide an endpoint with an associated set of permissions for establishing a session. Targets need to be associated with a host to establish a connection.

To set up some targets for this exercise, you need to connect HCP Boundary to your sandbox's Ingress worker. Some scripts are provided to automate this process for you.

For example, in the sandbox the following host exists:

• ubuntu-host

The host is configured with a hostname (address) of ubuntu-host. This is the address of the host in the lab environment that Boundary will use to start a connection. Functionally, a host provides the address where Boundary should attempt to start a session.

Targets provide further connection details, such as the protocol and port the connection should use. In this sandbox, two examples of targets are ubuntu-target-tcp and northwind-db. Both these targets are for services running on the ubuntu-host vm, at address boundary-target. The database target should connect to the host on port 5432, while ubuntu-target-tcp sets port 22 as the default port to enable SSH connections. HCP Boundary also provides ssh target types you will explore later.

The following Boundary users are preconfigured for SSH access on the ubuntu-host host:

• Priya:

  • username: priya
  • password: priya_password

• Oliver:

  • username: oliver
  • password: oliver_password

Khalid:

• username: khalid
• password: khalid_password

A postgres database is also configured on the ubuntu-host host and is available on port 5432:

• Database:
  • name: northwind
  • username: postgres
  • password: postgres

A Windows server target is configured to allow for password access for the following user:

• DomainUser:
  • username: DomainUser
  • password: DomainP@ssw0rd!!!

Access the Boundary Admin UI

You should log into the Boundary Admin UI at the URI for your HCP Boundary controller. You can find this URI in the HCP Boundary portal.

For example, your HCP Boundary Admin UI address may resemble the following:

https://aa40f8f1-ec39-4d10-b835-xxxxxxxxxxxx.boundary.hashicorp.cloud/

After configuring HCP Boundary using Terraform, the following resources are configured in your sandbox org:

• Org: sandbox org [timestamp]

• Project: sandbox project

• Host Catalogs:

• ubuntu-host-catalog

• windows-host-catalog

• Credential Store:

• ubuntu-host-creds

• windows-host-creds

• Targets:

• ubuntu-target-tcp

• ssh-recording-target-priya

• northwind-db

• windows-dc

• Aliases:

• priya

• sandbox.windows

• sandbox.northwind

• sandbox.ubuntu-target

You can access these targets from the Boundary workstation by configuring the CLI. Targets can also be accessed using the Boundary Desktop Client in the Workstation Desktop tab, or from on your local machine.

CLI Access

The shell in the Workstation tab has the Boundary, Vault, and Terraform CLI tools installed.

The following environment variables have been set:

• VAULT_ADDR=https://vault-server:8200

There are two ways you can log in to Boundary for these exercises:

• HCP Boundary admin user
• sandbox-user (configured by Terraform)

HCP Boundary requires you to create an admin user account when you first launch the cluster. You can use this user to get admin-level access from the CLI or the Boundary Desktop Client.

You can log into Boundary from the CLI using your HCP Boundary admin credentials:

$ boundary authenticate

If you used Terraform to configure the demo resources for the sandbox, two users will be preconfigured for you in the sandbox org:

• sandbox-user
  • Username: sandbox-user
  • Password: sandbox-user
• unprivileged
  • Username: unprivileged
  • Password: sandbox-user

You can log in with these users to learn more about how access in managed.

The sandbox-user account has permission to manage all resources within the sandbox org. You can use it to complete any of the sandbox exercises.

To log in with the sandbox-user configured by Terraform, you will need to locate the auth-method-id. You can find it in the Terraform outputs, or by running the following command in the ~/terraform directory:

$ terraform output

Export your auth-method-id as an environment variable:

$ export BOUNDARY_AUTH_METHOD_ID=ampw_ZbB6UXpW3B

Now you can log in using boundary authenticate and the sandbox-user credentials:

• Username: sandbox-user
• Password: sandbox-user

$ boundary authenticate
Please enter the login name (it will be hidden):
Please enter the password (it will be hidden):
 
Authentication information:
  Account ID:      acctpw_sC5a4GP9JA
  Auth Method ID:  ampw_CzkwJb5RRR
  Expiration Time: Thu, 03 Apr 2025 01:36:55 UTC
  User ID:         u_UURrzGLCik
 
The token name "default" was successfully stored in the chosen keyring and is not displayed here.

Exercise:

Connect to a target using the CLI

After authentication, you can connect to targets using the boundary connect command.

To connect to the northwind database on the ubuntu-host host, refer to the target by the alias sandbox.northwind:

$ boundary connect postgres sandbox.northwind
Credentials are being brokered but no -dbname parameter provided. psql may misinterpret another parameter as the database name.
psql (16.8 (Ubuntu 16.8-0ubuntu0.24.04.1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.
 
postgres=#

When you connect to the ubuntu-target target it will display the available brokered credentials for the oliver and priya users, and automatically select one of them to log you in as. Copy and paste or type the user's password to connect:

$ boundary connect ssh ubuntu-target
Credentials:
  Credential Source Description: Credentials for oliver user on ubuntu-host host
  Credential Source ID:          credup_XuqoTfBGrj
  Credential Source Name:        oliver-creds
  Credential Store ID:           csst_iHuwhwzstA
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   oliver_password
        username:   oliver
 
  Credential Source Description: Credentials for priya user on ubuntu-host host
  Credential Source ID:          credup_po69wMQRNN
  Credential Source Name:        priya-creds
  Credential Store ID:           csst_iHuwhwzstA
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   priya_password
        username:   priya
 
The authenticity of host 'hst_hi2n8ghvx8 ([127.0.0.1]:45223)' can't be established.
ED25519 key fingerprint is SHA256:kCPyzCG/O2ckQ5zvoxT1O9NTgNz+KNnTf+fDildd0QI.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'hst_hi2n8ghvx8' (ED25519) to the list of known hosts.
oliver@hst_hi2n8ghvx8's password:
oliver@ubuntu-host$

You can also select a user to authenticate as by passing additional login parameters to boundary connect ssh:

$ boundary connect ssh ubuntu-target -username priya
Credentials:
  Credential Source Description: Credentials for oliver user on ubuntu-host host
  Credential Source ID:          credup_XuqoTfBGrj
  Credential Source Name:        oliver-creds
  Credential Store ID:           csst_iHuwhwzstA
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   oliver_password
        username:   oliver
 
  Credential Source Description: Credentials for priya user on ubuntu-host host
  Credential Source ID:          credup_po69wMQRNN
  Credential Source Name:        priya-creds
  Credential Store ID:           csst_iHuwhwzstA
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   priya_password
        username:   priya
 
priya@hst_hi2n8ghvx8's password:
priya@ubuntu-host$

Connect using the Boundary Desktop Client

Open the Workstation Desktop tab. Launch the Boundary Desktop Client on the desktop.

Copy your HCP Boundary cluster address into the Boundary Desktop Client when prompted.

On the Sign In page, click the Choose a different scope dropdown and select sandbox org.

Log in using the following user credentials:

• HCP Boundary Cluster URI
• Org: sandbox org [timestamp]
• Username: sandbox-user
• Password: sandbox-user

This user was configured by Terraform. Its permissions are scoped to only allow access to the targets configured in the sandbox org. It does not allow access to any resources outside of the sandbox org.

You should see a list of the targets configured by Terraform.

If you do not see the targets, check that you successfully ran the terraform configure-boundary.sh script.

Click the Connect button next to a target, such as ssh-recording-target-priya.

From the sessions page, click the Shell tab. This will automatically launch the built-in terminal and attempt to open a session.

You should find a running session on the Sessions page. Try terminating the session from here. If session recording is enabled for your test target, verify that a recording was created.

Now, log out of the Boundary Desktop Client by clicking on the admin user dropdown and clicking "Sign Out".

On the Sign In page, click the Choose a different scope dropdown and select sandbox org again.

Log back in as the unprivileged user:

• Org: sandbox org [timestamp]
• Username: unprivileged
• Password: sandbox-user

What do you notice about this user's permissions? Do you have access to the same set of targets and hosts? How is this access configured?

You can learn more about grants and permissions in Boundary in the Permissions in Boundary docs.

Bonus: Connect from your local machine

On your local machine, you can use the Boundary Desktop Client to establish sessions.

HashiCorp recommends Windows and macOS users install the Boundary client components using the Boundary Installer:

• Boundary Installer

You can also install the Boundary Desktop Client directly instead:

• Boundary Desktop Client

After installing, open the Boundary Desktop Client.

Enter your HCP Boundary URL, and authenticate using the sandbox-user.

Try connecting to any of the targets like you did before in the browser.

Introduction to credential handling

Two types of credential handling are available in HCP Boundary:

1. Credential brokering
2. Credential injection

Credential brokering occurs when target credentials are sent directly back to the client for use in their shell.

The ubuntu-target-tcp target is configured using credential brokering.

If you request a session using boundary connect:

$ boundary connect -target-name ubuntu-target-tcp -target-scope-name "sandbox project"
Proxy listening information:
  Address:             127.0.0.1
  Connection Limit:    -1
  Expiration:          Thu, 11 Sep 2025 05:50:32 MDT
  Port:                50708
  Protocol:            tcp
  Session ID:          s_V1VU9SRtpS
 
  Credentials:
    Credential Source Description: Credentials for oliver user on ubuntu-host host
    Credential Source ID:          credup_3GaWPZ3mEj
    Credential Source Name:        oliver-creds
    Credential Store ID:           csst_0CQp4Oo4kx
    Credential Store Type:         static
    Credential Type:               username_password
    Secret:
          password:   oliver_password
          username:   oliver
 
    Credential Source Description: Credentials for priya user on ubuntu-host host
    Credential Source ID:          credup_9BGBG74JRl
    Credential Source Name:        priya-creds
    Credential Store ID:           csst_0CQp4Oo4kx
    Credential Store Type:         static
    Credential Type:               username_password
    Secret:
          password:   priya_password
          username:   priya

Then Boundary opens a proxy on the specified port, 50708 in this example. Notice that the proxy runs until the connection is manually closed, using ctrl+c.

If you had access to another shell session, the user would then able to connect to the target using their client of choice and the brokered credentials, such as oliver:

$ ssh 127.0.0.1 -p 38769 -l oliver
The authenticity of host '[127.0.0.1]:38769 ([127.0.0.1]:38769)' can't be established.
ED25519 key fingerprint is SHA256:fDiCeP2Ou6WZ3Eq8QdESwd6jGVBL0OHa8EbK1uMuGEw.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[127.0.0.1]:38769' (ED25519) to the list of known hosts.
oliver@127.0.0.1's password: 
oliver@ubuntu-host$ 

You can open a terminal in the Workstation Desktop tab if you want to try this workflow.

Otherwise, terminate the session using ctrl+c.

The user must pass brokered credentials directly, unless you use one of the Boundary connect helpers. A connect helper, such as ssh or psql, attempts to request a session and open it in a single command:

$ boundary connect ssh -target-name ubuntu-target-tcp -target-scope-name "sandbox project"
Credentials:
  Credential Source Description: Credentials for oliver user on ubuntu-host host
  Credential Source ID:          credup_LNvXHyngBa
  Credential Source Name:        oliver-creds
  Credential Store ID:           csst_gfwRVvu1S7
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   oliver_password
        username:   oliver
 
  Credential Source Description: Credentials for priya user on ubuntu-host host
  Credential Source ID:          credup_sD2MoO0sCd
  Credential Source Name:        priya-creds
  Credential Store ID:           csst_gfwRVvu1S7
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   priya_password
        username:   priya
 
The authenticity of host 'hst_hdxk4jjo03 ([127.0.0.1]:42837)' can't be established.
ED25519 key fingerprint is SHA256:fDiCeP2Ou6WZ3Eq8QdESwd6jGVBL0OHa8EbK1uMuGEw.
This host key is known by the following other names/addresses:
    ~/.ssh/known_hosts:1: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'hst_hdxk4jjo03' (ED25519) to the list of known hosts.
oliver@hst_hdxk4jjo03's password: 
oliver@ubuntu-host$

In this example, Boundary understands it should use the SSH protocol to handle any credentials available for the target. It uses the first set of credentials it finds, in this case, oliver. Boundary then attempts to pass the password on your behalf and establish a connection.

Credential brokering is very different from credential injection, which is available for Enterprise or HCP deployments. Credential injection requires a target type be set when creating the target. Compare the target types for ubuntu-target-tcp and ssh-recording-target-priya:

$ boundary search -resource targets   -query "name='ubuntu-target-tcp' OR name='ssh-recording-target-priya'"
 
Target information:
  ID:                    tssh_8ZGy748yYB
    Scope ID:            p_tRDxdhqrhg
    Version:             2
    Type:                ssh
    Name:                ssh-recording-target-priya
    Description:         SSH target
    Address:             ubuntu-host
    Authorized Actions:
      delete
      add-credential-sources
      no-op
      add-host-sources
      set-host-sources
      authorize-session
      update
      set-credential-sources
      read
      remove-host-sources
      remove-credential-sources
 
  ID:                    ttcp_8Na7RYxIG9
    Scope ID:            p_tRDxdhqrhg
    Version:             3
    Type:                tcp
    Name:                ubuntu-target-tcp
    Description:         SSH target for ubuntu-host
    Authorized Actions:
      remove-host-sources
      delete
      add-credential-sources
      set-credential-sources
      remove-credential-sources
      authorize-session
      update
      no-op
      read
      add-host-sources
      set-host-sources

Note that ubuntu-target-tcp is type tcp, while ssh-recording-target-priya is type ssh.

For credential injection to work, an ssh target must be assigned application injected credentials:

$ boundary targets read -id tssh_8ZGy748yYB
 
Target information:
  Address:                    ubuntu-host
  Created Time:               Fri, 08 May 2026 20:06:10 UTC
  Description:                SSH target
  Egress Worker Filter:       "egress" in "/tags/type"
  ID:                         tssh_8ZGy748yYB
  Name:                       ssh-recording-target-priya
  Session Connection Limit:   -1
  Session Max Seconds:        28800
  Type:                       ssh
  Updated Time:               Fri, 08 May 2026 20:06:11 UTC
  Version:                    2
 
  Scope:
    ID:                       p_tRDxdhqrhg
    Name:                     sandbox project
    Parent Scope ID:          o_DYvYF1M7Yw
    Type:                     project
 
  Authorized Actions:
    no-op
    read
    add-credential-sources
    authorize-session
    add-host-sources
    remove-credential-sources
    update
    set-credential-sources
    delete
    set-host-sources
    remove-host-sources
 
  Aliases:
    ID:                       alt_iuECSqKE7i
    Value:                    priya
 
  Injected Application Credential Sources:
    Credential Store ID:      csvlt_Fti67bybdx
    ID:                       clvlt_7zkbn4pQwz
 
  Attributes:
    Default Port:             22
    Enable Session Recording: true
    Storage Bucket ID:        sb_alDVLn6CMS

Here the credential clvlt_7zkbn4pQwz from credential store csvlt_Fti67bybdx is attached to the target. When a session is started, the attached credential is injected directly into the session, and never passed to the end user's shell.

$ boundary connect ssh -target-name ssh-recording-target-priya -target-scope-name "sandbox project"
priya@ubuntu-host$ 

Although this looks similar to the credential brokering workflow when using the ssh connect helper, it's important to note the functional difference. Brokered credentials are always passed back to the client's shell, even if they are passed on behalf of the user to start a session. Injected credentials are never sent back to the user. They are used by Boundary to initiate the session, and then the client is connected. Injected credentials are never exposed to the end client.

SSH targets can have both injected and brokered credentials attached to them. This is useful when the user needs additional credentials after the initial session has been established. An example is accessing a database after connecting to the target using SSH.

Exercise:

Set up a new static credential of type username and password for the khalid user:

username: khalid password: khalid_password

Use this credential in the next lesson to set up a new ssh target.

Boundary has built-in static credential management capabilities. If you are familiar with HashiCorp Vault, create a new credential library in the vault-ubuntu-credentials credential store for the khalid user.

$ source .bashrc
$ vault login $VAULT_ROOT_TOKEN
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.
 
Key                  Value
---                  -----
token                hvs.n69aVEhtLJM7rtocx7WRMaVa
token_accessor       DXtAVFy7vv8HUHAsBdtQTF6B
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

Refer to the existing configuration for the priya target to see an example for setting up the credential. This configuration is defined in the Terraform files:

~/terraform/targets.md

You can also look at the Boundary usage docs to learn about setting up Vault credentials using the Admin UI or CLI:

• Configure static Vault credentials
• Configure credential injection

Configure an SSH target for session recording

SSH targets in HCP Boundary and Boundary Enterprise enable the following features:

• Credential injection
• SSH session recording

Exercise

You may complete this exercise use the Admin UI, CLI, or Terraform.

1. Create a new ssh target called khalid-target

   • Set a target type of ssh
   • Set the default port to 22
   • Set an egress worker filter (required for session recording):
     • "egress" in "/tags/type"
   • Set a direct target address of ubuntu-host OR
   • Assign the ubuntu-targets-host-set by adding a host source

2. Assign an injected application credential to the target

   • Attach a static credential in Boundary OR

   • Attach the Vault credential library named ubuntu_khalid

   • Bonus: assign the target a target alias

     • Aliases simplify the target connection
     • Create an alias called sandbox.khalid

   • Bonus: enable session recording on the target

     • You must have assigned an egress worker filter when creating the target
     • Workers store and process recordings before uploading them to external storage (minio)

3. Verify the new target by connecting to it from the workstation

   • boundary connect ssh -target-name khalid-target -target-scope-name "sandbox project" or, connect by target ID (such as tssh_vE4VcjEMs7)
   • boundary connect ssh -target-id tssh_vE4VcjEMs7 or, use a target alias to connect to the target
   • boundary connect ssh sandbox.khalid

Enforce compliance standards with storage policies

Session recordings are used to enforce compliance standards for your organization. If you must comply with HIPPA or SOC standards, storage policies ensure records of sessions are retained for the required amount of time.

By default, session recordings are set with a retention policy of Forever, and cannot be deleted.

Exercise

Create a new retention policy that allows you to delete session recordings.

In the Boundary Admin UI:

1. Navigate to the Storage Policies page.

   • Select the sandbox org org from the top navigation bar.
   • Select Storage Policies from the left navigation panel.

2. Click Create a new storage policy.

   Fill in the form details:

   • Name: do-not-retain
   • Description: delete after 1 day
   • Retention Policy: Do not protect, allow deletion at any time
   • Deletion Policy: Custom
   • Delete after: 1 days

   Click Save.

3. Add the storage policy to the org.

   • From the left navigation panel, select Org Settings.
   • Click Add Storage Policy.
   • From the Add Storage Policy page, select the do-not-retain policy.

   Click Save.

4. Re-apply the storage policy to the session recording.

   • Navigate back to the Global scope and select Session Recordings from the left navigation panel.
   • Open a recording by clicking on View next to the recording. Under the Manage dropdown, select Re-apply storage policy.

5. Delete the session recording.

   • Click the Manage dropdown again, then select Delete recording and confirm the operation by clicking OK.

6. Repeat this process for any remaining recordings.

Bonus exercise

Implement a storage policy that conforms to SOC 2 retention policies (7 years):

• Retention Policy: SOC 2 (7 years)
• Deletion Policy: Custom Delete after: 2657 days Toggle the switch beside Allow orgs to override.

Explore how the HCP Boundary Sandbox is configured

The /home/learner/get-started/ARCHITECTURE.md file describes the architecture of this sandbox environment.

This includes the following components:

• Boundary controller (self-hosted postgres)
• Ingress Boundary worker
• Egress Boundary worker
• Vault server
• MinIO storage backend
• Ubuntu target

Examine these components and answer the following questions:

• What are the requirements for these components?
• How must they be configured to create a functional and secure Boundary deployment?
• How do the ingress and egress workers function in a multi-hop sessions deployment, and how can this provide enhanced security for your network?

You can check the controller or worker configurations by examining /etc/boundary.d/boundary.hcl file on the those hosts.

Use the following documentation to deepen your understanding:

• Boundary Enterprise reference architecture
• Boundary Enterprise deployment guide
• System requirements
• Recommended architecure
• controller stanza
• worker stanza
• Configure workers
• Vault integration

Bring your own targets

Configure your own targets with your HCP Boundary environment.

This exercise requires that you spin up hosts in an external environment.

Some possibilities include:

• A cloud providers, like AWS, GCP, or Microsoft Azure
• Local VMs or containers on your own machine

You must set up a Boundary worker with access to the targets you want to connect to. You need at least one worker (an egress worker to connect to the target), but if you only configure a single worker then you may have to expose the worker's public address for Boundary to connect to it.

HCP Boundary and Boundary Enterprise allow for multi-hop session worker configurations, where an ingress worker handles the initial connection from Boundary, then continues to "hop" to the next worker in the chain until it reaches the egress worker. Both the ingress an egress workers must be configured on the target, while any intermediate workers are set up as part of the worker configuration file as upstreams.

A single egress worker is recommended for a proof-of-concept. You can learn more about multi-hop sessions here:

Deploy workers

Set up a target with Docker

As an example, you can create docker containers on your local machine.

Docker can be used to deploy an openssh-server target.

1. Ensure Docker is running, and then deploy an openssh container to use as a target.

   $ docker run -d \
     --name openssh-server \
     -e USER_NAME=admin \
     -e PASSWORD_ACCESS=true \
     -e USER_PASSWORD=password \
     -p 2222:2222 \
     lscr.io/linuxserver/openssh-server:latest
   

   Note that the username for the openssh server is admin, the password is password, and the target is available on your localhost at port 2222 (127.0.0.1:2222).

   Check that the container is running.

   $ docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Image}}\t{{.Status}}"
   CONTAINER ID   NAMES            IMAGE                                          STATUS
   6e63f8178576   openssh-server   lscr.io/linuxserver/openssh-server:latest   Up    20 seconds
   

2. Configure a worker.

   You can deploy a Boundary worker with Docker to provide access to the openssh target container.

   When using this image as a worker with HCP Boundary or Boundary Enterprise, you do not need to provide the license using an environment variable or config, but the worker must connect with a licensed controller.

   Note

   If your cluster is configured for multi-hop sessions, add an upstream worker for initial_upstreams instead.

   Create a new file in your working directory called config.hcl.

   Supply the controller DNS for the initial_upstreams, which is the a resolvable address for the HCP Boundary cluster. If your cluster is listening on a port other than 9201, then change that value too.

   listener "tcp" {
     address = "127.0.0.1:9202"
     purpose = "proxy"
   }
    
   worker {
     initial_upstreams = ["<YOUR_CONTROLLER_ADDRESS>:9201"]
     public_addr = "openssh-worker"
     auth_storage_path = "/tmp/openssh-worker"
     recording_storage_path = "/tmp/boundary"
     tags {
       type = ["worker", "openssh"]
     }
   }
   

   Save the config.hcl file.

3. Deploy the worker.

   Open a new terminal and switch to the directory with the config.hcl file, then deploy the boundary-enterprise Docker container. It will automatically source the config file if you deploy it where the file is located.

   $ docker run \
     --network host \
     --hostname=openssh-worker \
     -v "$(pwd)":/boundary/ \
     hashicorp/boundary-enterprise
   

   The worker will start attempting to connect to the controller.

   In this example, the worker is connecting with a worker-led auth token. A controller-led workflow instead uses a shared KMS so the worker can register itself.

   Scroll to the top of the output and copy the Worker Auth Registration Request value.

   Export the Worker Auth Request Token value as an environment variable.

   $ export WORKER_TOKEN="<Worker Auth Registration Request Value>"
   

4. Register the worker.

   You can register the worker using the Admin Console Web UI or the CLI.

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

   $ boundary authenticate
   Please enter the login name (it will be hidden):
   Please enter the password (it will be hidden):
   Authentication information:
     Account ID:      acctpw_VOeNSFX8pQ
     Auth Method ID:  ampw_ZbB6UXpW3B
     Expiration Time: Thu, 15 Aug 2025 12:35:32 MST
     User ID:         u_ogz79sV4sT
   The token was successfully stored in the chosen keyring and is not displayed here.
   

   Tip

   If you get the following error:

   Error looking up primary auth method ID for the global scope. Try setting a primary auth method for the global scope, or use an auth method subcomma (see 'boundary authenticate -h' for available sub command usage).

   then you may have a provisioning issue with the sandbox. Relaunch the sandbox and try again.

   The token is used to issue a create worker request that authorizes 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, 12 Aug 2025 19:54:57 MDT
     ID:                        w_IPfR7jBVri
     Local Storage State:       unknown
     Type:                      pki
     Updated Time:              Mon, 12 Aug 2025 19:54:57 MDT
     Version:                   1
    
     Scope:
       ID:                      global
       Name:                    global
       Type:                    global
    
     Authorized Actions:
       update
       delete
       add-worker-tags
       set-worker-tags
       remove-worker-tags
       no-op
       read
   

5. Create credentials for the openssh-target.

   If you want to enable session recording, credential injection must be set up. This requires you to create a new credential for the target.

   Locate the sandbox project scope id.

   Create a new static credential store:

   $ boundary credential-stores create static \
     -name "SSH Credentials" \
     -scope-id $PROJECT_ID
   

   Copy the credential store ID from the output, such as csst_xNlFeo0sIb.

   The openssh password attribute must be passed as an environment variable, or from a file. Export it as an env var:

   $ export OPENSSH_PASSWORD=password
   

   Create a new credential of type username-password. Pass in the credential store ID you copied in the last step.

   $ boundary credentials create username-password \
     -name "openssh credentials" \
     -credential-store-id $BOUNDARY_CRED_STORE_ID \
     -username admin \
     -password env://OPENSSH_PASSWORD
   

   Copy the credential ID from the output, such as credup_d0vdR0XxCw.

6. Create a new target.

   Create a target for the openssh host. You can create the target using the CLI or Admin UI.

   An egress worker filter specifies which worker has access to the target, such as a worker deployed in the same network as the target. An ingress worker specifies how to route a Boundary client to the target network, and is not used in this example.

   Recall the tags associated with the openssh-worker, which also provides access to the openssh host:

   Tags:
     Configuration:
       type: ["worker" "openssh"]
     Canonical:
       type: ["worker" "openssh"]
   

   The tags for this worker are:

   "type" = ["worker", "openssh"]

   An appropriate filter to select this worker is:

   "openssh" in "/tags/type"
   

   Create a new target of type ssh named openssh-target.

   Set the default port to 2222. To optionally enable session recording, pass the storage bucket ID and egress worker filter. You can get the project ID and storage bucket ID (such as sb_nzFv30oX2E) from the Admin UI or CLI.

   $ boundary targets create ssh -scope-id $PROJECT_ID \
     -name "openssh-target" \
     -alias "openssh.target" \
     -session-connection-limit -1 \
     -address "127.0.0.1" \
     -default-port 2222 \
     -egress-worker-filter '"openssh" in "/tags/type"' \
     -storage-bucket-id=$STORAGE_BUCKET_ID \
     -enable-session-recording=true
   

   Copy the target ID from the output, such as tssh_4B5TnVtlbb.

   Now associate openssh-target with the credential library. Pass in the target ID and credential ID you copied earlier.

   $ boundary targets add-credential-sources -id $TARGET_ID -injected-application-credential-source $TARGET_CREDENTIAL_ID
   

7. Test the target connection.

   From the boundary-workstation, test the openssh-target.

   Enter yes when prompted to establish the connection.

   $ boundary connect ssh -target-id $TARGET_ID
   Welcome to OpenSSH Server
   3fe7e57f5505:~$
   

What is a Boundary target?

Targets are a Boundary resource that represent a networked service or host that a user can connect to. Targets provide an endpoint with an associated set of permissions for establishing a session. Targets need to be associated with a host to establish a connection.

For example, in the sandbox the following host exists:

• ubuntu-host

The host is configured with a hostname (address) of ubuntu-target. This is the address of the host in the lab environment that Boundary will use to start a connection. Functionally, a host provides the address where a session should be attempted.

Targets provide further connection details, such as the protocol and port the connection should use. In this sandbox, two examples of targets are ubuntu-target-tcp and northwind-db. Both these targets are for services running on the ubuntu-target vm, at address boundary-target. The database target should connect to the host on port 5432, while ubuntu-target-tcp sets port 22 as the default port to enable SSH connections. In Boundary Enterprise, there are also ssh target types you will explore later.

The following Boundary users are preconfigured for SSH access on the ubuntu-target host:

• Priya:

  • username: priya
  • password: priya_password

• Oliver:

  • username: oliver
  • password: oliver_password

• Khalid:

  • username: khalid
  • password: khalid_password

A postgres database is also configured on the ubuntu-target host and is available on port 5432:

• Database:
  • name: northwind
  • username: postgres
  • password: postgres

A Windows Server target is configured to allow for password access for the following user:

• instruqt:
  • username: instruqt
  • password: Passw0rd!

Access the Boundary Admin UI

You can log in to the Boundary Admin UI in the Boundary Admin UI tab.

To log into the Boundary Admin UI, use the following credentials for the admin user:

• Username: admin
• Password: password

Or log in as the unprivileged user:

• Username: user
• Password: password

Within Boundary the following resources are configured:

• Org: sandbox org

• Project: sandbox project

• Host Catalogs:

  • ubuntu-host-catalog
  • controller-host-catalog

• Credential Store:

  • ubuntu-target-creds

• Targets:

  • boundary-db (Boundary's local database)
  • northwind-db (on ubuntu-host host)
  • ubuntu-target-tcp (on ubuntu-host host)
  • ssh-recording-target-priya (on ubuntu-host host)

• Aliases:

  • priya

You can access these targets from the Boundary workstation by configuring the CLI. Targets can also be accessed using the Boundary Desktop client on your local machine.

CLI Access

The shell in the Boundary workstation tab has the Boundary, Vault, and Terraform CLI tools installed.

The following environment variables have been set:

• BOUNDARY_ADDR=http://controller:9200
• VAULT_ADDR=http://vault-server:8200

You can log into Boundary from the CLI: using the admin credentials:

• Username: admin
• Password: password

$ boundary authenticate
Please enter the login name (it will be hidden):
Please enter the password (it will be hidden):
 
Authentication information:
  Account ID:      acctpw_sC5a4GP9JA
  Auth Method ID:  ampw_CzkwJb5RRR
  Expiration Time: Thu, 03 Apr 2025 01:36:55 UTC
  User ID:         u_UURrzGLCik
 
The token name "default" was successfully stored in the chosen keyring and is not displayed here.

Exercise:

Connect to a target using the CLI

After authentication, you can connect to targets using the boundary connect command.

Connect to the northwind database on the ubuntu-target host:

$ boundary connect postgres northwind
Credentials are being brokered but no -dbname parameter provided. psql may misinterpret another parameter as the database name.
psql (16.8 (Ubuntu 16.8-0ubuntu0.24.04.1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.
 
postgres=#

When you connect to the ubuntu-target host it will display the available brokered credentials for the oliver and priya users, and automatically select one of them to log you in as. Copy and paste or type the user's password to connect:

$ boundary connect ssh ubuntu-target
Credentials:
  Credential Source Description: Credentials for oliver user on ubuntu-target host
  Credential Source ID:          credup_XuqoTfBGrj
  Credential Source Name:        oliver-creds
  Credential Store ID:           csst_iHuwhwzstA
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   oliver_password
        username:   oliver
 
  Credential Source Description: Credentials for priya user on ubuntu-target host
  Credential Source ID:          credup_po69wMQRNN
  Credential Source Name:        priya-creds
  Credential Store ID:           csst_iHuwhwzstA
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   priya_password
        username:   priya
 
The authenticity of host 'hst_hi2n8ghvx8 ([127.0.0.1]:45223)' can't be established.
ED25519 key fingerprint is SHA256:kCPyzCG/O2ckQ5zvoxT1O9NTgNz+KNnTf+fDildd0QI.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'hst_hi2n8ghvx8' (ED25519) to the list of known hosts.
oliver@hst_hi2n8ghvx8's password:
oliver@ubuntu-target$

Select a user to authenticate as by passing additional login parameters to boundary connect ssh:

$ boundary connect ssh ubuntu-target -username priya
Credentials:
  Credential Source Description: Credentials for oliver user on ubuntu-target host
  Credential Source ID:          credup_XuqoTfBGrj
  Credential Source Name:        oliver-creds
  Credential Store ID:           csst_iHuwhwzstA
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   oliver_password
        username:   oliver
 
  Credential Source Description: Credentials for priya user on ubuntu-target host
  Credential Source ID:          credup_po69wMQRNN
  Credential Source Name:        priya-creds
  Credential Store ID:           csst_iHuwhwzstA
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   priya_password
        username:   priya
 
priya@hst_hi2n8ghvx8's password:
priya@ubuntu-target$

Bonus: Connect using the Boundary Desktop Client

On your local machine, you can use the Boundary Desktop Client to establish sessions.

HashiCorp recommends Windows and macOS users install the Boundary client components using the Boundary Installer:

• Boundary Installer

You can also install the Boundary Desktop Client directly instead:

• Boundary Desktop Client

After installing, open the Boundary Desktop Client.

Locate your Boundary Controller's public URL in the /home/learner/get-started/public-controller-url file.

Copy this and paste it into the Boundary Desktop Client when prompted.

Authenticate to Boundary using the admin user credentials:

• Username: admin
• Password: password

Click the Connect button next to a target, such as ssh-recording-target-priya.

From the sessions page, click the Shell tab. This will automatically launch the built-in terminal and attempt to open a session.

You should find a running session on the Sessions page. Try terminating the session from here. If session recording is enabled for your test target, verify that a recording was created.

Now, log out of the Boundary Desktop Client by clicking on the admin user dropdown and clicking "Sign Out".

On the Sign In page, click the Choose a different scope dropdown and select sandbox org.

Log back in as the unprivileged user:

• Org: sandbox org
• Username: user
• Password: password

What do you notice about this user's permissions? Do you have access to the same set of targets and hosts?

You can learn more about grants and permissions in Boundary in the Permissions in Boundary docs.

Introduction to credential handling

Two types of credential handling are available in Boundary Enterprise:

1. Credential brokering
2. Credential injection

Credential brokering occurs when target credentials are sent directly back to the client for use in their shell.

The ubuntu-target-tcp target is configured using credential brokering.

If you request a session using boundary connect:

$ boundary connect -target-name ubuntu-target-tcp -target-scope-name "sandbox project"
Proxy listening information:
  Address:             127.0.0.1
  Connection Limit:    -1
  Expiration:          Thu, 11 Sep 2025 05:50:32 MDT
  Port:                50708
  Protocol:            tcp
  Session ID:          s_V1VU9SRtpS
 
  Credentials:
    Credential Source Description: Credentials for oliver user on ubuntu-target host
    Credential Source ID:          credup_3GaWPZ3mEj
    Credential Source Name:        oliver-creds
    Credential Store ID:           csst_0CQp4Oo4kx
    Credential Store Type:         static
    Credential Type:               username_password
    Secret:
          password:   oliver_password
          username:   oliver
 
    Credential Source Description: Credentials for priya user on ubuntu-target host
    Credential Source ID:          credup_9BGBG74JRl
    Credential Source Name:        priya-creds
    Credential Store ID:           csst_0CQp4Oo4kx
    Credential Store Type:         static
    Credential Type:               username_password
    Secret:
          password:   priya_password
          username:   priya

Then a proxy is opened on the specified port, 50708 in this example. Notice that the proxy runs until the connection is manually closed, using ctrl+c. The user is then able to connect to the target using their client of choice and the brokered credentials, such as oliver:

$ ssh 127.0.0.1 -p 38769 -l oliver
The authenticity of host '[127.0.0.1]:38769 ([127.0.0.1]:38769)' can't be established.
ED25519 key fingerprint is SHA256:fDiCeP2Ou6WZ3Eq8QdESwd6jGVBL0OHa8EbK1uMuGEw.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[127.0.0.1]:38769' (ED25519) to the list of known hosts.
oliver@127.0.0.1's password: 
oliver@ubuntu-target$ 

The user must pass these credentials directly, unless you use one of the Boundary connect helpers. A connect helper, such as ssh or psql, attempts to request a session and open it in a single command:

$ boundary connect ssh -target-name ubuntu-target-tcp -target-scope-name "sandbox project"
Credentials:
  Credential Source Description: Credentials for oliver user on ubuntu-target host
  Credential Source ID:          credup_LNvXHyngBa
  Credential Source Name:        oliver-creds
  Credential Store ID:           csst_gfwRVvu1S7
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   oliver_password
        username:   oliver
 
  Credential Source Description: Credentials for priya user on ubuntu-target host
  Credential Source ID:          credup_sD2MoO0sCd
  Credential Source Name:        priya-creds
  Credential Store ID:           csst_gfwRVvu1S7
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   priya_password
        username:   priya
 
The authenticity of host 'hst_hdxk4jjo03 ([127.0.0.1]:42837)' can't be established.
ED25519 key fingerprint is SHA256:fDiCeP2Ou6WZ3Eq8QdESwd6jGVBL0OHa8EbK1uMuGEw.
This host key is known by the following other names/addresses:
    ~/.ssh/known_hosts:1: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'hst_hdxk4jjo03' (ED25519) to the list of known hosts.
oliver@hst_hdxk4jjo03's password: 
oliver@ubuntu-target$

In this example, Boundary understands it should use the SSH protocol to handle any credentials available for the target. It uses the first set of credentials it finds, in this case, oliver. Boundary then passes the password on your behalf and establishes a connection.

Credential brokering is very different from credential injection, which is available for Enterprise or HCP deployments. Credential injection requires a target type be set when creating the target. Compare the target types for ubuntu-target-tcp and ssh-recording-target-priya:

$ boundary search -resource targets -query "name='ubuntu-target-tcp' OR name='ssh-recording-target-priya'"
 
Target information:
  ID:                    tssh_vE4VcjEMs6
    Scope ID:            p_RwEjU2ZTlT
    Version:             2
    Type:                ssh
    Name:                ssh-recording-target-priya
    Description:         SSH target
    Address:             ubuntu-target
    Authorized Actions:
      add-host-sources
      no-op
      authorize-session
      set-credential-sources
      remove-credential-sources
      read
      update
      delete
      set-host-sources
      remove-host-sources
      add-credential-sources
 
  ID:                    ttcp_RVWygmdtmr
    Scope ID:            p_RwEjU2ZTlT
    Version:             3
    Type:                tcp
    Name:                ubuntu-target-tcp
    Description:         SSH target for ubuntu-target
    Authorized Actions:
      read
      update
      delete
      remove-host-sources
      add-credential-sources
      add-host-sources
      set-credential-sources
      remove-credential-sources
      no-op
      set-host-sources
      authorize-session

Note that ubuntu-target-tcp is type tcp, while ssh-recording-target-priya is type ssh.

For credential injection to work, an ssh target must be assigned application injected credentials:

$ boundary targets read -id tssh_vE4VcjEMs6
 
Target information:
  Address:                    ubuntu-target
  Created Time:               Thu, 11 Sep 2025 03:57:11 UTC
  Description:                SSH target
  Egress Worker Filter:       "egress" in "/tags/type"
  ID:                         tssh_vE4VcjEMs6
  Name:                       ssh-recording-target-priya
  Session Connection Limit:   -1
  Session Max Seconds:        28800
  Type:                       ssh
  Updated Time:               Thu, 11 Sep 2025 03:57:12 UTC
  Version:                    2
 
  Scope:
    ID:                       p_RwEjU2ZTlT
    Name:                     sandbox project
    Parent Scope ID:          o_OLcERTET5o
    Type:                     project
 
  Authorized Actions:
    update
    delete
    set-host-sources
    add-credential-sources
    authorize-session
    add-host-sources
    set-credential-sources
    remove-host-sources
    remove-credential-sources
    no-op
    read
 
  Aliases:
    ID:                       alt_KVDgkMbVzE
    Value:                    priya
 
  Injected Application Credential Sources:
    Credential Store ID:      csst_gfwRVvu1S7
    ID:                       credup_sD2MoO0sCd
 
  Attributes:
    Default Port:             22
    Enable Session Recording: true
    Storage Bucket ID:        sb_5PyYvthvUt

Here the credential credup_sD2MoO0sCd from credential store csst_gfwRVvu1S7 is attached to the target. When a session is started, the attached credential is injected directly into the session, and never passed to the end user's shell.

$ boundary connect ssh -target-name ssh-recording-target-priya -target-scope-name "sandbox project"
priya@ubuntu-target$ 

Although this looks similar to the credential brokering workflow when using the ssh connect helper, it's important to note the functional difference. Brokered credentials are always passed back to the client's shell, even if they are passed on behalf of the user to start a session. Injected credentials are never sent back to the user. They are used by Boundary to initiate the session, and then the client is connected. Injected credentials are never exposed to the end client.

SSH targets can have both injected and brokered credentials attached to them. This is useful when the user needs additional credentials after the initial session has been established, for example, accessing a database after conneting using SSH.

Exercise:

Set up a new static credential of type username and password for the Oliver user:

username: oliver password: oliver_password

This credential can be used to set up a new ssh target for Oliver, like the Priya user. The difference between these two credentials is that the ubuntu_priya credential is stored in a Vault credential store, while Oliver's credential is stored within Boundary.

Creating credentials allows end users to authenticate to targets. In the next exercise, you will create a new target and attach a credential to in.

Boundary has built-in static credential management capabilities. If you are familiar with HashiCorp Vault, examine the Vault credential library called the ubuntu_khalid. This credential is sourced from Vault like the Priya credential, and is used in Exercise 3.

$ source .bashrc
$ vault login $VAULT_ROOT_TOKEN
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.
 
Key                  Value
---                  -----
token                hvs.n69aVEhtLJM7rtocx7WRMaVa
token_accessor       DXtAVFy7vv8HUHAsBdtQTF6B
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

After you finish experimenting with creating credentials, move on the Exercise 3.

Configure an SSH target for session recording

SSH targets in Boundary Enterprise enable the following features:

• Credential injection
• SSH session recording

Exercise

You may complete this exercise use the Admin UI, CLI, or Terraform.

1. Create a new ssh target called khalid-target

   • Set a target type of ssh
   • Set the default port to 22
   • Set an egress worker filter (required for session recording):
     • "egress" in "/tags/type"
   • Set a direct target address of ubuntu-host OR
   • Assign the ubuntu-targets-host-set by adding a host source

2. Assign an injected application credential to the target

   • Attach a static credential in Boundary OR

   • Attach the Vault credential library named ubuntu_khalid

   • Bonus: assign the target a target alias

     • Aliases simplify the target connection
     • Create an alias called sandbox.khalid

   • Bonus: enable session recording on the target

     • You must have assigned an egress worker filter when creating the target
     • Workers store and process recordings before uploading them to external storage (minio)

3. Verify the new target by connecting to it from the workstation

   • boundary connect ssh -target-name khalid-target -target-scope-name "sandbox project" or, connect by target ID (such as tssh_vE4VcjEMs7)
   • boundary connect ssh -target-id tssh_vE4VcjEMs7 or, use a target alias to connect to the target
   • boundary connect ssh sandbox.khalid

Enforce compliance standards with storage policies

Session recordings are used to enforce compliance standards for your organization. If you must comply with HIPPA or SOC standards, storage policies ensure records of sessions are retained for the required amount of time.

By default, session recordings are set with a retention policy of Forever, and cannot be deleted.

Exercise

Create a new retention policy that allows you to delete session recordings.

In the Boundary Admin UI:

1. Navigate to the Storage Policies page.

• Select the sandbox org org from the top navigation bar.
• Select Storage Policies from the left navigation panel.

1. Click Create a new storage policy.

Fill in the form details:

• Name: do-not-retain
• Description: delete after 1 day
• Retention Policy: Do not protect, allow deletion at any time
• Deletion Policy: Custom
• Delete after: 1 days

Click Save.

1. Add the storage policy to the org.

• From the left navigation panel, select Org Settings.
• Click Add Storage Policy.
• From the Add Storage Policy page, select the do-not-retain policy.

Click Save.

1. Re-apply the storage policy to the session recording.

• Navigate back to the Global scope and select Session Recordings from the left navigation panel.
• Open a recording by clicking on View next to the recording. Under the Manage dropdown, select Re-apply storage policy.

1. Delete the session recording.

• Click the Manage dropdown again, then select Delete recording and confirm the operation by clicking OK.

Repeat this process for any remaining recordings.

Bonus exercise

Implement a storage policy that conforms to SOC 2 retention policies (7 years):

• Retention Policy: SOC 2 (7 years)
• Deletion Policy: Custom Delete after: 2657 days Toggle the switch beside Allow orgs to override.

Explore how Boundary Enterprise is deployed

The /home/learner/get-started/ARCHITECTURE.md file describes the architecture of this sandbox environment.

This includes the following components:

• Boundary controller (self-hosted postgres)
• Ingress Boundary worker
• Egress Boundary worker
• Vault server
• MinIO storage backend
• Ubuntu target

Examine these components and answer the following questions:

• What are the requirements for these components?
• How must they be configured to create a functional and secure Boundary deployment?
• How do the ingress and egress workers function in a multi-hop sessions deployment, and how can this provide enhanced security for your network?

You can check the controller or worker configurations by examining /etc/boundary.d/boundary.hcl file on the those hosts.

Use the following documentation to deepen your understanding:

• Boundary Enterprise reference architecture
• Boundary Enterprise deployment guide
• System requirements
• Recommended architecure
• controller stanza
• worker stanza
• Configure workers
• Vault integration

Bring your own targets

Configure your own targets with your Boundary Enterprise environment.

This exercise requires that you spin up hosts in an external environment.

Some possibilities include:

• A cloud providers, like AWS, GCP, or Microsoft Azure
• Local VMs or containers on your own machine

You must set up a Boundary worker with access to the targets you want to connect to. You need at least one worker (an egress worker to connect to the target), but if you only configure a single worker then you may have to expose the worker's public address for Boundary to connect to it.

Boundary Enterprise allows for multi-hop session worker configurations, where an ingress worker handles the initial connection from Boundary, then continues to "hop" to the next worker in the chain until it reaches the egress worker. Both the ingress an egress workers must be configured on the target, while any intermediate workers are set up as part of the worker configuration file as upstreams.

A single egress worker is recommended for a proof-of-concept. You can learn more about multi-hop sessions here:

Deploy workers

Set up a target with Docker

As an example, you can create docker containers on your local machine.

Docker can be used to deploy an openssh-server target.

1. Ensure Docker is running, and then deploy an openssh container to use as a target.

   $ docker run -d \
     --name openssh-server \
     -e USER_NAME=admin \
     -e PASSWORD_ACCESS=true \
     -e USER_PASSWORD=password \
     -p 2222:2222 \
     lscr.io/linuxserver/openssh-server:latest
   

   Note that the username for the openssh server is admin, the password is password, and the target is available on your localhost at port 2222 (127.0.0.1:2222).

   Check that the container is running.

   $ docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Image}}\t{{.Status}}"
   CONTAINER ID   NAMES            IMAGE                                          STATUS
   6e63f8178576   openssh-server   lscr.io/linuxserver/openssh-server:latest   Up    20 seconds
   

2. Configure a worker.

   You can deploy a Boundary worker with Docker to provide access to the openssh target container.

   When using this image as a worker with HCP Boundary or Boundary Enterprise, you do not need to provide the license using an environment variable or config, but the worker must connect with a licensed controller.

   Note

   If your cluster is configured for multi-hop sessions, add an upstream worker for initial_upstreams instead.

   Create a new file in your working directory called config.hcl.

   Supply the controller DNS for the initial_upstreams, which is the a resolvable address for the Boundary Enterprise cluster. If your cluster is listening on a port other than 9201, then change that value too.

   listener "tcp" {
     address = "127.0.0.1:9202"
     purpose = "proxy"
   }
    
   worker {
     initial_upstreams = ["<YOUR_CONTROLLER_ADDRESS>:9201"]
     public_addr = "openssh-worker"
     auth_storage_path = "/tmp/openssh-worker"
     recording_storage_path = "/tmp/boundary"
     tags {
       type = ["worker", "openssh"]
     }
   }
   

   Save the config.hcl file.

3. Deploy the worker.

   Open a new terminal and switch to the directory with the config.hcl file, then deploy the boundary-enterprise Docker container. It will automatically source the config file if you deploy it where the file is located.

   $ docker run \
     --network host \
     --hostname=openssh-worker \
     -v "$(pwd)":/boundary/ \
     hashicorp/boundary-enterprise
   

   The worker will start attempting to connect to the controller.

   In this example, the worker is connecting with a worker-led auth token. A controller-led workflow instead uses a shared KMS so the worker can register itself.

   Scroll to the top of the output and copy the Worker Auth Registration Request value.

   Export the Worker Auth Request Token value as an environment variable.

   $ export WORKER_TOKEN="<Worker Auth Registration Request Value>"
   

4. Register the worker.

   You can register the worker using the Admin Console Web UI or the CLI.

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

   $ boundary authenticate
   Please enter the login name (it will be hidden):
   Please enter the password (it will be hidden):
   Authentication information:
     Account ID:      acctpw_VOeNSFX8pQ
     Auth Method ID:  ampw_ZbB6UXpW3B
     Expiration Time: Thu, 15 Aug 2025 12:35:32 MST
     User ID:         u_ogz79sV4sT
   The token was successfully stored in the chosen keyring and is not displayed here.
   

   Tip

   If you get the following error:

   Error looking up primary auth method ID for the global scope. Try setting a primary auth method for the global scope, or use an auth method subcomma (see 'boundary authenticate -h' for available sub command usage).

   then you may have a provisioning issue with the sandbox. Relaunch the sandbox and try again.

   The token is used to issue a create worker request that authorizes 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, 12 Aug 2025 19:54:57 MDT
     ID:                        w_IPfR7jBVri
     Local Storage State:       unknown
     Type:                      pki
     Updated Time:              Mon, 12 Aug 2025 19:54:57 MDT
     Version:                   1
    
     Scope:
       ID:                      global
       Name:                    global
       Type:                    global
    
     Authorized Actions:
       update
       delete
       add-worker-tags
       set-worker-tags
       remove-worker-tags
       no-op
       read
   

5. Create credentials for the openssh-target.

   If you want to enable session recording, credential injection must be set up. This requires you to create a new credential for the target.

   Locate the sandbox project scope id.

   Create a new static credential store:

   $ boundary credential-stores create static \
     -name "SSH Credentials" \
     -scope-id $PROJECT_ID
   

   Copy the credential store ID from the output, such as csst_xNlFeo0sIb.

   The openssh password attribute must be passed as an environment variable, or from a file. Export it as an env var:

   $ export OPENSSH_PASSWORD=password
   

   Create a new credential of type username-password. Pass in the credential store ID you copied in the last step.

   $ boundary credentials create username-password \
     -name "openssh credentials" \
     -credential-store-id $BOUNDARY_CRED_STORE_ID \
     -username admin \
     -password env://OPENSSH_PASSWORD
   

   Copy the credential ID from the output, such as credup_d0vdR0XxCw.

6. Create a new target.

   Create a target for the openssh host. You can create the target using the CLI or Admin UI.

   An egress worker filter specifies which worker has access to the target, such as a worker deployed in the same network as the target. An ingress worker specifies how to route a Boundary client to the target network, and is not used in this example.

   Recall the tags associated with the openssh-worker, which also provides access to the openssh host:

   Tags:
     Configuration:
       type: ["worker" "openssh"]
     Canonical:
       type: ["worker" "openssh"]
   

   The tags for this worker are:

   "type" = ["worker", "openssh"]

   An appropriate filter to select this worker is:

   "openssh" in "/tags/type"
   

   Create a new target of type ssh named openssh-target.

   Set the default port to 2222. To optionally enable session recording, pass the storage bucket ID and egress worker filter. You can get the project ID and storage bucket ID (such as sb_nzFv30oX2E) from the Admin UI or CLI.

   $ boundary targets create ssh -scope-id $PROJECT_ID \
     -name "openssh-target" \
     -alias "openssh.target" \
     -session-connection-limit -1 \
     -address "127.0.0.1" \
     -default-port 2222 \
     -egress-worker-filter '"openssh" in "/tags/type"' \
     -storage-bucket-id=$STORAGE_BUCKET_ID \
     -enable-session-recording=true
   

   Copy the target ID from the output, such as tssh_4B5TnVtlbb.

   Now associate openssh-target with the credential library. Pass in the target ID and credential ID you copied earlier.

   $ boundary targets add-credential-sources -id $TARGET_ID -injected-application-credential-source $TARGET_CREDENTIAL_ID
   

7. Test the target connection.

   From the boundary-workstation, test the openssh-target.

   Enter yes when prompted to establish the connection.

   $ boundary connect ssh -target-id $TARGET_ID
   Welcome to OpenSSH Server
   3fe7e57f5505:~$
   

What is a Boundary target?

Targets are a Boundary resource that represent a networked service or host that a user can connect to. Targets provide an endpoint with an associated set of permissions for establishing a session. Targets need to be associated with a host to establish a connection.

For example, in the sandbox the following host exists:

• ubuntu-host

The host is configured with a hostname (address) of ubuntu-host. This is the address of the host in the lab environment that Boundary will use to start a connection. Functionally, a host provides the address where a session should be attempted.

Targets provide further connection details, such as the protocol and port the connection should use. In this sandbox, two examples of targets are ubuntu-target-tcp and northwind-db. Both these targets are for services running on the ubuntu-target vm, at address boundary-target. The database target should connect to the host on port 5432, while ubuntu-target-tcp sets port 22 as the default port to enable SSH connections. TCP targets are the only target types available in Boundary Community Edition.

The following Boundary users are preconfigured for SSH access on the ubuntu-target host:

• Priya:

  • username: priya
  • password: priya_password

• Oliver:

  • username: oliver
  • password: oliver_password

• Khalid:

  • username: khalid
  • password: khalid_password

A postgres database is also configured on the ubuntu-target host and is available on port 5432:

• Database:
  • name: northwind
  • username: postgres
  • password: postgres

Access the Boundary Admin UI

You can log in to the Boundary Admin UI in the Boundary Admin UI tab.

To log into the Boundary Admin UI, use the following credentials for the admin user:

• Username: admin
• Password: password

Or log in as the unprivileged user:

• Username: user
• Password: password

Within Boundary the following resources are configured:

• Org: sandbox org

• Project: sandbox project

• Host Catalogs:

  • ubuntu-host-catalog
  • controller-host-catalog

• Credential Store:

  • ubuntu-target-creds

• Targets:

  • boundary-db (Boundary's local database)
  • northwind-db (on ubuntu-host host)
  • ubuntu-target-ssh (on ubuntu-host host)
  • priya-target-ssh (on ubuntu-host host)

• Aliases:

  • priya

You can access these targets from the Boundary workstation by configuring the CLI. Targets can also be accessed using the Boundary Desktop client on your local machine.

CLI Access

The shell in the Boundary workstation tab has the Boundary, Vault, and Terraform CLI tools installed.

The following environment variables have been set:

• BOUNDARY_ADDR=http://controller:9200
• VAULT_ADDR=http://vault-server:8200

You can log into Boundary from the CLI: using the admin credentials:

• Username: admin
• Password: password

$ boundary authenticate
Please enter the login name (it will be hidden):
Please enter the password (it will be hidden):
 
Authentication information:
  Account ID:      acctpw_sC5a4GP9JA
  Auth Method ID:  ampw_CzkwJb5RRR
  Expiration Time: Thu, 03 Apr 2025 01:36:55 UTC
  User ID:         u_UURrzGLCik
 
The token name "default" was successfully stored in the chosen keyring and is not displayed here.

Exercise:

Connect to a target using the CLI

After authentication, you can connect to targets using the boundary connect command.

Connect to the northwind database on the ubuntu-target host:

$ boundary connect postgres northwind
Credentials are being brokered but no -dbname parameter provided. psql may misinterpret another parameter as the database name.
psql (16.8 (Ubuntu 16.8-0ubuntu0.24.04.1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.
 
postgres=#

When you connect to the ubuntu-target host it will display the available brokered credentials for the oliver and priya users, and automatically select one of them to log you in as. Copy and paste or type the user's password to connect:

$ boundary connect ssh ubuntu-target
Credentials:
  Credential Source Description: Credentials for oliver user on ubuntu-target host
  Credential Source ID:          credup_XuqoTfBGrj
  Credential Source Name:        oliver-creds
  Credential Store ID:           csst_iHuwhwzstA
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   oliver_password
        username:   oliver
 
  Credential Source Description: Credentials for priya user on ubuntu-target host
  Credential Source ID:          credup_po69wMQRNN
  Credential Source Name:        priya-creds
  Credential Store ID:           csst_iHuwhwzstA
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   priya_password
        username:   priya
 
The authenticity of host 'hst_hi2n8ghvx8 ([127.0.0.1]:45223)' can't be established.
ED25519 key fingerprint is SHA256:kCPyzCG/O2ckQ5zvoxT1O9NTgNz+KNnTf+fDildd0QI.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'hst_hi2n8ghvx8' (ED25519) to the list of known hosts.
oliver@hst_hi2n8ghvx8's password:
oliver@ubuntu-target$

Select a user to authenticate as by passing additional login parameters to boundary connect ssh:

$ boundary connect ssh ubuntu-target -username priya
Credentials:
  Credential Source Description: Credentials for oliver user on ubuntu-target host
  Credential Source ID:          credup_XuqoTfBGrj
  Credential Source Name:        oliver-creds
  Credential Store ID:           csst_iHuwhwzstA
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   oliver_password
        username:   oliver
 
  Credential Source Description: Credentials for priya user on ubuntu-target host
  Credential Source ID:          credup_po69wMQRNN
  Credential Source Name:        priya-creds
  Credential Store ID:           csst_iHuwhwzstA
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   priya_password
        username:   priya
 
priya@hst_hi2n8ghvx8's password:
priya@ubuntu-target$

Bonus: Connect using the Boundary Desktop Client

On your local machine, you can use the Boundary Desktop Client to establish sessions.

HashiCorp recommends Windows and macOS users install the Boundary client components using the Boundary Installer:

• Boundary Installer

You can also install the Boundary Desktop Client directly instead:

• Boundary Desktop Client

After installing, open the Boundary Desktop Client.

Locate your Boundary Controller's public URL in the /home/learner/get-started/public-controller-url file.

Copy this and paste it into the Boundary Desktop Client when prompted.

Authenticate to Boundary using the admin user credentials:

• Username: admin
• Password: password

Click the Connect button next to a target, such as priya-target-ssh.

From the sessions page, click the Shell tab. This will automatically launch the built-in terminal and attempt to open a session.

You should find a running session on the Sessions page. Try terminating the session from here. If session recording is enabled for your test target, verify that a recording was created.

Now, log out of the Boundary Desktop Client by clicking on the admin user dropdown and clicking "Sign Out".

On the Sign In page, click the Choose a different scope dropdown and select sandbox org.

Log back in as the unprivileged user:

• Org: sandbox org
• Username: user
• Password: password

What do you notice about this user's permissions? Do you have access to the same set of targets and hosts?

You can learn more about grants and permissions in Boundary in the Permissions in Boundary docs.

Introduction to credential handling

Two types of credential handling are available in Boundary:

1. Credential brokering
2. Credential injection (Boundary Enterprise or HCP Boundary)

Credential brokering occurs when target credentials are sent directly back to the client for use in their shell. This type of credential handling is available in Boundary Community Edition.

The ubuntu-target-tcp target is configured using credential brokering.

If you request a session using boundary connect:

$ boundary connect -target-name ubuntu-target-tcp -target-scope-name "sandbox project"
Proxy listening information:
  Address:             127.0.0.1
  Connection Limit:    -1
  Expiration:          Thu, 11 Sep 2025 05:50:32 MDT
  Port:                50708
  Protocol:            tcp
  Session ID:          s_V1VU9SRtpS
 
  Credentials:
    Credential Source Description: Credentials for oliver user on ubuntu-target host
    Credential Source ID:          credup_3GaWPZ3mEj
    Credential Source Name:        oliver-creds
    Credential Store ID:           csst_0CQp4Oo4kx
    Credential Store Type:         static
    Credential Type:               username_password
    Secret:
          password:   oliver_password
          username:   oliver
 
    Credential Source Description: Credentials for priya user on ubuntu-target host
    Credential Source ID:          credup_9BGBG74JRl
    Credential Source Name:        priya-creds
    Credential Store ID:           csst_0CQp4Oo4kx
    Credential Store Type:         static
    Credential Type:               username_password
    Secret:
          password:   priya_password
          username:   priya

Then a proxy is opened on the specified port, 50708 in this example. Notice that the proxy runs until the connection is manually closed, using ctrl+c. The user is then able to connect to the target using their client of choice and the brokered credentials, such as oliver:

$ ssh 127.0.0.1 -p 38769 -l oliver
The authenticity of host '[127.0.0.1]:38769 ([127.0.0.1]:38769)' can't be established.
ED25519 key fingerprint is SHA256:fDiCeP2Ou6WZ3Eq8QdESwd6jGVBL0OHa8EbK1uMuGEw.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[127.0.0.1]:38769' (ED25519) to the list of known hosts.
oliver@127.0.0.1's password: 
oliver@ubuntu-target$ 

The user must pass these credentials directly, unless you use one of the Boundary connect helpers. A connect helper, such as ssh or psql, attempts to request a session and open it in a single command:

$ boundary connect ssh -target-name ubuntu-target-tcp -target-scope-name "sandbox project"
Credentials:
  Credential Source Description: Credentials for oliver user on ubuntu-target host
  Credential Source ID:          credup_LNvXHyngBa
  Credential Source Name:        oliver-creds
  Credential Store ID:           csst_gfwRVvu1S7
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   oliver_password
        username:   oliver
 
  Credential Source Description: Credentials for priya user on ubuntu-target host
  Credential Source ID:          credup_sD2MoO0sCd
  Credential Source Name:        priya-creds
  Credential Store ID:           csst_gfwRVvu1S7
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   priya_password
        username:   priya
 
The authenticity of host 'hst_hdxk4jjo03 ([127.0.0.1]:42837)' can't be established.
ED25519 key fingerprint is SHA256:fDiCeP2Ou6WZ3Eq8QdESwd6jGVBL0OHa8EbK1uMuGEw.
This host key is known by the following other names/addresses:
    ~/.ssh/known_hosts:1: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'hst_hdxk4jjo03' (ED25519) to the list of known hosts.
oliver@hst_hdxk4jjo03's password: 
oliver@ubuntu-target$

In this example, Boundary understands it should use the SSH protocol to handle any credentials available for the target. It uses the first set of credentials it finds, in this case, oliver. Boundary then passes the password on your behalf and establishes a connection.

Credential brokering is very different from credential injection, which is available for Enterprise or HCP deployments. Credential injection handles credentials without exposing them to end-users, meaning a Boundary client never receives or handles the credential.

Credential injection requires the SSH or RDP target types available in Boundary Enterprise, instead of the TCP targets you are experimenting with in this sandbox.

To experiment with credential injection and other enterprise features, check out the Boundary Enterprise Sandbox.

Exercise:

Set up a new static credential of type username and password for the khalid user:

username: khalid password: khalid_password

Use this credential in the next lesson to set up a new ssh target.

Boundary has built-in static credential management capabilities. If you are familiar with HashiCorp Vault, create a new credential library in the vault-ubuntu-credentials credential store for the khalid user.

$ source .bashrc
$ vault login $VAULT_ROOT_TOKEN
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.
 
Key                  Value
---                  -----
token                hvs.n69aVEhtLJM7rtocx7WRMaVa
token_accessor       DXtAVFy7vv8HUHAsBdtQTF6B
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

After you finish experimenting with creating credentials, move on the Exercise 3.

Configure a TCP target

TCP targets in Boundary allow clients to connect to any generic target, such as databases, SSH or RDP servers, or Kubernetes API servers.

The following targets and target aliases are already set up:

Targets:

• boundary-db
• northwind-db
• ubuntu-target-ssh
• priya-target-ssh

Aliases:

• northwind
• boundary-db
• ubuntu-target
• priya

Exercise

You may complete this exercise use the Admin UI, CLI, or Terraform.

1. Create a new ssh target called khalid-target

   • Set a target type of tcp
   • Set the default port to 22
   • Set an egress worker filter (required for session recording):
     • "worker" in "/tags/type"
   • Set a direct target address of ubuntu-host OR
   • Assign the ubuntu-host-set by adding a host source

2. Assign a brokered application credential to the target

   • Attach a static credential in Boundary OR

   • Attach the Vault credential library named ubuntu_khalid

   • Bonus: assign the target a target alias

     • Aliases simplify the target connection
     • Create an alias called sandbox.khalid

3. Verify the new target by connecting to it from the workstation

   • boundary connect ssh -target-name khalid-target -target-scope-name "sandbox project" or, connect by target ID (such as tssh_vE4VcjEMs7)
   • boundary connect ssh -target-id tssh_vE4VcjEMs7 or, use a target alias to connect to the target
   • boundary connect ssh sandbox.khalid

Explore how Boundary Community Edition is deployed

The /home/learner/get-started/ARCHITECTURE.md file describes the architecture of this sandbox environment.

This includes the following components:

• Boundary controller (self-hosted postgres)
• Boundary worker
• Vault server
• Ubuntu target

Examine these components and answer the following questions:

• What are the requirements for these components?
• How must they be configured to create a functional and secure Boundary deployment?
• How does the worker provide access to the target network? Boundary Community Edition only allows for egress workers, which provide access to targets. How can the ingress workers provided in HCP Boundary and Boundary Enterprise improve an organization's security posture?

You can check the controller or worker configurations by examining /etc/boundary.d/boundary.hcl file on the those hosts.

Use the following documentation to deepen your understanding:

• Boundary Enterprise reference architecture
• Boundary Enterprise deployment guide
• System requirements
• Recommended architecure
• controller stanza
• worker stanza
• Configure workers
• Vault integration

Bring your own targets

Configure your own targets with your Boundary environment.

This exercise requires that you spin up hosts in an external environment.

Some possibilities include:

• A cloud providers, like AWS, GCP, or Microsoft Azure
• Local VMs or containers on your own machine

You must set up a Boundary worker with access to the targets you want to connect to. You need at least one worker (an egress worker to connect to the target), but if you only configure a single worker then you may have to expose the worker's public address for Boundary to connect to it.

Boundary workers provide access to the targets you want to connect to. Deploying a worker is required for this exercise. You can learn more about setting up a worker here:

Deploy workers

Set up a target with Docker

As an example, you can create docker containers on your local machine.

Docker can be used to deploy an openssh-server target.

1. Ensure Docker is running, and then deploy an openssh container to use as a target.

   $ docker run -d \
     --name openssh-server \
     -e USER_NAME=admin \
     -e PASSWORD_ACCESS=true \
     -e USER_PASSWORD=password \
     -p 2222:2222 \
     lscr.io/linuxserver/openssh-server:latest
   

   Note that the username for the openssh server is admin, the password is password, and the target is available on your localhost at port 2222 (127.0.0.1:2222).

   Check that the container is running.

   $ docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Image}}\t{{.Status}}"
   CONTAINER ID   NAMES            IMAGE                                          STATUS
   6e63f8178576   openssh-server   lscr.io/linuxserver/openssh-server:latest   Up    20 seconds
   

2. Configure a worker.

   You can deploy a Boundary worker with Docker to provide access to the openssh target container.

   When using this image as a worker with HCP Boundary or Boundary Enterprise, you do not need to provide the license using an environment variable or config, but the worker must connect with a licensed controller.

   Create a new file in your working directory called config.hcl.

   Supply the controller DNS for the initial_upstreams, which is the a resolvable address for the Boundary cluster. If your cluster is listening on a port other than 9201, then change that value too.

   listener "tcp" {
     address = "127.0.0.1:9202"
     purpose = "proxy"
   }
    
   worker {
     initial_upstreams = ["<YOUR_CONTROLLER_ADDRESS>:9201"]
     public_addr = "openssh-worker"
     auth_storage_path = "/tmp/openssh-worker"
     tags {
       type = ["worker", "openssh"]
     }
   }
   

   Save the config.hcl file.

3. Deploy the worker.

   Open a new terminal and switch to the directory with the config.hcl file, then deploy the boundary Docker container. It will automatically source the config file if you deploy it where the file is located.

   $ docker run \
     --network host \
     --hostname=openssh-worker \
     -v "$(pwd)":/boundary/ \
     hashicorp/boundary
   

   The worker will start attempting to connect to the controller.

   In this example, the worker is connecting with a worker-led auth token. A controller-led workflow instead uses a shared KMS so the worker can register itself.

   Scroll to the top of the output and copy the Worker Auth Registration Request value.

   Export the Worker Auth Request Token value as an environment variable.

   $ export WORKER_TOKEN="<Worker Auth Registration Request Value>"
   

4. Register the worker.

   You can register the worker using the Admin Console Web UI or the CLI.

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

   $ boundary authenticate
   Please enter the login name (it will be hidden):
   Please enter the password (it will be hidden):
   Authentication information:
     Account ID:      acctpw_VOeNSFX8pQ
     Auth Method ID:  ampw_ZbB6UXpW3B
     Expiration Time: Thu, 15 Aug 2025 12:35:32 MST
     User ID:         u_ogz79sV4sT
   The token was successfully stored in the chosen keyring and is not displayed here.
   

   Tip

   If you get the following error:

   Error looking up primary auth method ID for the global scope. Try setting a primary auth method for the global scope, or use an auth method subcommand (see 'boundary authenticate -h' for available sub command usage).

   then you may have a provisioning issue with the sandbox. Relaunch the sandbox and try again.

   The token is used to issue a create worker request that authorizes 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, 12 Aug 2025 19:54:57 MDT
     ID:                        w_IPfR7jBVri
     Local Storage State:       unknown
     Type:                      pki
     Updated Time:              Mon, 12 Aug 2025 19:54:57 MDT
     Version:                   1
    
     Scope:
       ID:                      global
       Name:                    global
       Type:                    global
    
     Authorized Actions:
       update
       delete
       add-worker-tags
       set-worker-tags
       remove-worker-tags
       no-op
       read
   

5. Create credentials for the openssh-target.

   Locate the sandbox project scope id.

   Create a new static credential store:

   $ boundary credential-stores create static \
     -name "SSH Credentials" \
     -scope-id $PROJECT_ID
   

   Copy the credential store ID from the output, such as csst_xNlFeo0sIb.

   The openssh password attribute must be passed as an environment variable, or from a file. Export it as an env var:

   $ export OPENSSH_PASSWORD=password
   

   Create a new credential of type username-password. Pass in the credential store ID you copied in the last step.

   $ boundary credentials create username-password \
     -name "openssh credentials" \
     -credential-store-id $BOUNDARY_CRED_STORE_ID \
     -username admin \
     -password env://OPENSSH_PASSWORD
   

   Copy the credential ID from the output, such as credup_d0vdR0XxCw.

6. Create a new target.

   Create a target for the openssh host. You can create the target using the CLI or Admin UI.

   An egress worker filter specifies which worker has access to the target, such as a worker deployed in the same network as the target.

   Recall the tags associated with the openssh-worker, which also provides access to the openssh host:

   Tags:
     Configuration:
       type: ["worker" "openssh"]
     Canonical:
       type: ["worker" "openssh"]
   

   The tags for this worker are:

   "type" = ["worker", "openssh"]

   An appropriate filter to select this worker is:

   "openssh" in "/tags/type"
   

   Create a new target of type tcp named openssh-target.

   Set the default port to 2222, and set the egress worker filter. You can get the project ID from the Admin UI or CLI.

   $ boundary targets create tcp -scope-id $PROJECT_ID \
     -name "openssh-target" \
     -alias "openssh.target" \
     -session-connection-limit -1 \
     -address "127.0.0.1" \
     -default-port 2222 \
     -egress-worker-filter '"openssh" in "/tags/type"'
   

   Copy the target ID from the output, such as tssh_4B5TnVtlbb.

   Now associate openssh-target with the credential library. Pass in the target ID and credential ID you copied earlier.

   $ boundary targets add-credential-sources -id $TARGET_ID -brokered-application-credential-source $TARGET_CREDENTIAL_ID
   

7. Test the target connection.

   From the boundary-workstation, test the openssh-target.

   Enter yes when prompted to establish the connection.

   $ boundary connect ssh -target-id $TARGET_ID
   Welcome to OpenSSH Server
   3fe7e57f5505:~$