Create a web TCP target

TCP targets provide a generic way to connect to any service Boundary has access to, including HTTP and HTTPS services.

The following examples use a direct target address for simplicity, but HashiCorp recommends that you configure host catalogs and host sets for scaled production deployments.

Complete the following steps to create a TCP target to connect to a web service. This example assumes an HTTPS service.

Log in to Boundary.
Select an org, and then select the project where you want to create a target.
Select Targets under Project Actions.
Click New Target.
Complete the following fields:
- Name: (Required) A name for identification purposes. The name must be unique.
- Description: (Optional) An optional description of the target for identification purposes.
- Type: (Required) Select TCP to create a TCP target.
- Target Address (Optional) If you are not using host catalogs and host sets, you can enter a target address instead to map the target to a single address. This must be a valid IP address or DNS name.
- Default Port (Required) The default port on which to connect, such as 443.
- Aliases (Optional) A globally-scoped unique identifier for the target, which makes the target easier to connect to using the CLI or transparent sessions. If you create an alias, click Add to assign it.
Click Save.

Log in to Boundary.
Set the BOUNDARY_PROJECT_ID environment variable, or provide the scope ID (such as p_1234567890) in the next step.
Use the following command to create an SSH target named postgres-dev-server with an alias postgres, with a direct target address of 10.0.0.5 and a default connection port of 5432:
```
$ boundary targets create tcp \
  -scope-id $BOUNDARY_PROJECT_ID \
  -name "test-example-web-server" \
  -with-alias-value "test.example.com" \
  -address "10.0.0.30" \
  -default-port 443
```
You must provide the scope-id field when you create a target.
Refer to the targets domain model documentation for more fields that you can use when you create targets, and the targets create command for all the CLI options.

You can define a target and target alias using the Boundary Terraform provider:

resource "boundary_target" "example" {
  name         = "test-example-web-server"
  description  = "Apache web server for test.example.com"
  type         = "tcp"
  address      = "10.0.0.30"
  default_port = "443"
  scope_id     = boundary_scope.project.id
}

resource "boundary_alias_target" "test.example.com" {
  name                      = "test-example-web-server"
  description               = "Target alias for test-example-web-server"
  scope_id                  = "global"
  value                     = "test.example.com"
  destination_id            = boundary_target.example.id
}

Configure a brokered application credential

You can configure a brokered application credential for end users to connect to the target. Brokered credentials are exposed to the end user to allow them to authenticate to a target manually, or using connect helpers.

You can configure credentials for the TCP target using:

Static credentials (username_password or ssh_private_key)
Vault generic credential library

Refer to the Configure targets with credential brokering page to learn how to configure a target with credential brokering.

Example

The following scenario assumes:

A web server is deployed in your private network (Nginx, Apache, IIS, etc).
A Boundary worker is deployed in your network and registered with the Boundary control plane.
Your application domain has a registered DNS A-record and is resolvable by authenticated users on your network.
SSL-signed certificates are installed on your web server, and you have distributed the root certificate to clients you want to connect to the web target. Clients should add the cert to their keychain to trust the CA that generated it.
Your users have been onboarded to Boundary, manually or using an authentication method like OIDC or LDAP.
You have created an org and a project where you want to set up the web target. This example calls the org dev-projects and the project web-infrastructure. The example may refer to the org by ID (such as o_c2Ah7bPMj5) or the project by ID (such as p_UXVxIgpZ8U), depending on whether you follow the UI, CLI, or Terraform workflows.

This example also assumes that you want to set up an access model with the following permissions:

Unauthenticated users cannot access the address range
Authenticated but unauthorized users cannot view the web target
Authenticated and authorized users can start sessions to web target

This access model allows users connected to the web target through Boundary to access the address range, but they cannot connect to the target unless you grant a user access to it.

With these prerequisites in place, you can set up the permissions and targets to restrict access to the web target to an authenticated user. This example grants access to a single user, but using a group for authenticated users is more realistic.

Configure users and grants

To model the different access protocols, you should create an authorized and unauthorized user. These represent users that should and should not have access to the web application hosted on the target.

Create the unauthorized and authorized users:

Log in to Boundary.
Make sure you are in the global scope. The left sidebar will confirm you are at the Global Level.
Select Users under Global IAM.
Create an unauthorized user:
1. Click New User.
2. Complete the following fields:
  - Name: (Required) A name for identification purposes. The name must be unique. This example calls the user unauthorized.
  - Description: (Optional) An optional description of the target for identification purposes.
Create an authorized user:
1. Navigate back to the Users page and click New User.
2. Complete the following fields:
  - Name: (Required) A name for identification purposes. The name must be unique. This example calls the user authorized.
  - Description: (Optional) An optional description of the target for identification purposes.
3. Click Save.

Assign minimal permissions to the unauthorized user in the `global` scope:

Make sure you are in the global scope.
Click Roles in the sidebar. Click New Role.
Complete the following fields:
- Name: (Required) A name for identification purposes. The name must be unique. This example calls the role unauthorized_global_role.
- Description: (Optional) An optional description of the target for identification purposes. Click Save.
Select the Principals tab for the new role. Click Add Principals.
Select the box next to the unauthorized user in the global scope and click Add Principals.
Select the Grants tab for the role.
In the New Grant field, enter the grant string: type=auth-token;ids=*;actions=read:self, then click Add.
Add another grant in the New Grant field: type=user;actions=list-resolvable-aliases;ids=*, then click Add.
Click Save.

There are two grant strings in the example above:

"type=auth-token;ids=*;actions=read:self" This grant ensures that the user can authenticate to the Client Agent, if you are using a transparent sessions workflow. "type=user;actions=list-resolvable-aliases;ids=*" This grant ensures that the user can read the aliases in a transparent sessions workflow.

Assign read permissions to the authorized user in the `global` scope:

Make sure you are in the global scope.
Click Roles in the sidebar. Click New Role.
Complete the following fields:
- Name: (Required) A name for identification purposes. The name must be unique. This example calls the role authorized_global_role.
- Description: (Optional) An optional description of the target for identification purposes. Click Save.
Select the Principals tab for the new role. Click Add Principals.
Select the box next to the authorized user in the global scope and click Add Principals.
Select the Grants tab for the role.
In the New Grant field, enter the grant string: ids=*;type=*;actions=read, then click Add.
Add another grant in the New Grant field: type=auth-token;ids=*;actions=read:self, then click Add.
Add another grant in the New Grant field: type=user;actions=list-resolvable-aliases;ids=*, then click Add.
Click Save.

The grant string "ids=*;type=*;actions=read" ensures that the user can read all resources in the global scope.

Assign full access permissions for the authorized user in the org scope:

Click on Back to Global on the upper-right part of the page.
On the Orgs page, select the name of your org (such as dev-projects or the ID like o_c2Ah7bPMj5).
Click Roles in the sidebar. Click New Role.
Complete the following fields:
- Name: (Required) A name for identification purposes. The name must be unique. This example calls the role authorized_org_role.
- Description: (Optional) An optional description of the target for identification purposes. Click Save.
Select the Principals tab for the new role. Click Add Principals.
Select the box next to the authorized user in the global scope and click Add Principals.
Select the Grants tab for the role.
In the New Grant field, enter the grant string: ids=*;type=*;actions=*, then click Add.
Click Save.

The grant string "ids=*;type=*;actions=*" ensures that the user can perform all actions in the scope.

Assign full access permissions for the authorized user in the project scope:

Select Projects in the left-hand sidebar under Org Level.
On the Projects page, select the name of your project (such as web-infrastructure or the ID like p_UXVxIgpZ8U).
Click Roles in the sidebar. Click New Role.
Complete the following fields:
- Name: (Required) A name for identification purposes. The name must be unique. This example calls the role authorized_project_role.
- Description: (Optional) An optional description of the target for identification purposes. Click Save.
Select the Principals tab for the new role. Click Add Principals.
Select the box next to the authorized user in the global scope and click Add Principals.
Select the Grants tab for the role.
In the New Grant field, enter the grant string: ids=*;type=*;actions=*, then click Add.
Click Save.

Create the unauthorized and authorized users:

Create an unauthorized user and limit its permissions.

Log in to Boundary.
Set the BOUNDARY_PROJECT_ID environment variable, or provide the scope ID (such as p_1234567890) in the next step.

Create an unauthorized user:

$ boundary users create -scope-id $BOUNDARY_PROJECT_ID -name "unauthorized"

User information:
  Created Time:        Thu, 15 Jan 2026 19:25:48 MST
  ID:                  u_2pA1bPrvjl
  Name:                unauthorized
  Updated Time:        Thu, 15 Jan 2026 19:25:48 MST
  Version:             1

  Scope:
    ID:                o_c2Ah7bPMj5
    Name:
    Parent Scope ID:   global
    Type:              org

  Authorized Actions:
    no-op
    read
    update
    delete
    add-accounts
    set-accounts
    remove-accounts
    list-resolvable-aliases

Copy the user id, such as u_2pA1bPrvjl.

Create a new role for the unauthorized user called unauthorized_global_role:

$ boundary roles create -scope-id global -name "unauthorized_global_role"

Role information:
  Created Time:        Thu, 15 Jan 2026 19:22:38 MST
  ID:                  r_jOyos6VIZR
  Name:                unauthorized_global_role
  Updated Time:        Thu, 15 Jan 2026 19:22:38 MST
  Version:             1

  Scope:
    ID:                global
    Name:              global
    Type:              global

  Authorized Actions:
    add-grant-scopes
    update
    set-grant-scopes
    no-op
    add-principals
    delete
    remove-principals
    remove-grant-scopes
    read
    set-principals
    add-grants
    set-grants
    remove-grants

  Grant Scope IDs:
    ID:             this

Copy the role id, such as r_jOyos6VIZR.

Add grants to the role. Use your own role ID in the command.

$ boundary roles add-grants -id r_jOyos6VIZR -grant "type=auth-token;ids=*;actions=read:self" -grant "type=user;actions=list-resolvable-aliases;ids=*"

Role information:
  Created Time:        Thu, 15 Jan 2026 19:22:38 MST
  ID:                  r_jOyos6VIZR
  Name:                unauthorized
  Updated Time:        Thu, 15 Jan 2026 19:32:51 MST
  Version:             2

  Scope:
    ID:                global
    Name:              global
    Type:              global

  Authorized Actions:
    remove-grant-scopes
    add-principals
    add-grant-scopes
    update
    delete
    remove-principals
    no-op
    read
    set-principals
    add-grants
    set-grants
    remove-grants
    set-grant-scopes

  Canonical Grants:
    ids=*;type=auth-token;actions=read:self
    ids=*;type=user;actions=list-resolvable-aliases

  Grant Scope IDs:
    ID:             this

There are two grant strings in the example above:

Assign the unauthorized user as a principal to the unauthorized role. Replace the example role ID and user ID with your own. Note that you could also use a group here, instead of assigning a user as the principal.

$ boundary roles add-principals -id r_jOyos6VIZR -principal u_2pA1bPrvjl

Role information:
  Created Time:        Thu, 15 Jan 2026 19:22:38 MST
  ID:                  r_jOyos6VIZR
  Name:                unauthorized
  Updated Time:        Thu, 15 Jan 2026 19:33:47 MST
  Version:             3

  Scope:
    ID:                global
    Name:              global
    Type:              global

  Authorized Actions:
    set-principals
    set-grants
    remove-grants
    update
    delete
    remove-principals
    set-grant-scopes
    add-grants
    add-grant-scopes
    remove-grant-scopes
    no-op
    read
    add-principals

  Principals:
    ID:             u_2pA1bPrvjl
      Type:         user
      Scope ID:     o_c2Ah7bPMj5

  Canonical Grants:
    ids=*;type=auth-token;actions=read:self
    ids=*;type=user;actions=list-resolvable-aliases

  Grant Scope IDs:
    ID:             this

Create an authorized user, granting it read access in the `global` scope:

Create an authorized user:

$ boundary users create -scope-id $BOUNDARY_PROJECT_ID -name "authorized"

User information:
  Created Time:        Thu, 15 Jan 2026 19:34:59 MST
  ID:                  u_JogL5yWuKP
  Name:                authorized
  Updated Time:        Thu, 15 Jan 2026 19:34:59 MST
  Version:             1

  Scope:
    ID:                o_c2Ah7bPMj5
    Name:
    Parent Scope ID:   global
    Type:              org

  Authorized Actions:
    list-resolvable-aliases
    no-op
    read
    update
    delete
    add-accounts
    set-accounts
    remove-accounts

Copy the user id, such as u_JogL5yWuKP.

Create a new role in the global scope for the authorized user:

$ boundary roles create -scope-id global -name "authorized_global_role"

Role information:
  Created Time:        Thu, 15 Jan 2026 19:36:43 MST
  ID:                  r_6MuGPBkg8d
  Name:                authorized_global_role
  Updated Time:        Thu, 15 Jan 2026 19:36:43 MST
  Version:             1

  Scope:
    ID:                global
    Name:              global
    Type:              global

  Authorized Actions:
    update
    set-principals
    remove-principals
    delete
    set-grants
    remove-grant-scopes
    add-principals
    add-grant-scopes
    set-grant-scopes
    no-op
    read
    add-grants
    remove-grants

  Grant Scope IDs:
    ID:             this

Copy the role id, such as r_6MuGPBkg8d.

Add grants to the role. Use your own role ID in the command.

$ boundary roles add-grants -id r_6MuGPBkg8d -grant "ids=*;type=*;actions=read" -grant "type=auth-token;ids=*;actions=read:self" -grant "type=user;actions=list-resolvable-aliases;ids=*"

Role information:
  Created Time:        Thu, 15 Jan 2026 19:36:43 MST
  ID:                  r_6MuGPBkg8d
  Name:                authorized_global_role
  Updated Time:        Thu, 15 Jan 2026 19:39:43 MST
  Version:             2

  Scope:
    ID:                global
    Name:              global
    Type:              global

  Authorized Actions:
    delete
    remove-grant-scopes
    read
    add-principals
    set-principals
    add-grants
    set-grants
    add-grant-scopes
    remove-principals
    set-grant-scopes
    no-op
    remove-grants
    update

  Canonical Grants:
    ids=*;type=*;actions=read
    ids=*;type=auth-token;actions=read:self
    ids=*;type=user;actions=list-resolvable-aliases

  Grant Scope IDs:
    ID:             this

The grant string "ids=*;type=*;actions=read" ensures that the user can read all resources in the global scope.

Grant the authorized user full access in the org and project scopes:

Create an authorized_org_role and authorized_project_role with full access grants.

Create a new role called authorized_org_role in the org scope for the authorized user. Provide your own org ID, such as o_c2Ah7bPMj5.
```
$ boundary roles create -scope-id o_c2Ah7bPMj5 -name "authorized_org_role"
```
Copy the role id, such as r_92hVjrgcEN.
Add full access grants to the role. Use your own role ID in the command.
```
$ boundary roles add-grants -id r_92hVjrgcEN -grant "ids=*;type=*;actions=*"
```
The grant string "ids=*;type=*;actions=*" ensures that the user can perform all actions in the scope.
Assign the authorized user as a principal to the authorized_org_role role. Replace the example role ID and user ID with your own.
```
$ boundary roles add-principals -id r_92hVjrgcEN -principal u_JogL5yWuKP
```
Repeat this process to create the authorized_project_role with full access grants "ids=*;type=*;actions=*" for the authorized user.

You can define Boundary resources using the Boundary Terraform provider.

Create an unauthorized user:

resource "boundary_account_password" "unauthorized_user" {
  auth_method_id = boundary_auth_method.password.id
  login_name     = "unauthorized"
  password       = "unauthorized"
}

Assign minimal permissions to the unauthorized user:

resource "boundary_role" "unauthorized" {
 description = "Unauthorized user read-auth-token"
 grant_strings = [
   "type=auth-token;ids=*;actions=read:self",
   "type=user;actions=list-resolvable-aliases;ids=*",
 ]
 name          = "unauthorized_global_role"
 principal_ids = [boundary_user.unauthorized_user.id]
 scope_id      = "global"
}

There are two grant strings in the example above:

Create an authorized user:

resource "boundary_account_password" "authorized_user" {
  auth_method_id = boundary_auth_method.password.id
  login_name     = "authorized"
  password       = "authorized"
}

Assign read permissions to the authorized user in the global scope, and full access permissions in the org and projects scope:

resource "boundary_role" "authorized_global_role" {
  name          = "authorized_global_role"
  description   = "Authorized Global Role"
  scope_id      = "global"
  principal_ids = [boundary_user.authorized_user.id]
  grant_strings = [
    "ids=*;type=*;actions=read",
    "type=auth-token;ids=*;actions=read:self",
    "type=user;actions=list-resolvable-aliases;ids=*",
  ]
}

resource "boundary_role" "authorized_org_role" {
  name          = "authorized_org_role"
  description   = "Authorized Org Role"
  scope_id      = boundary_scope.org.id
  principal_ids = [boundary_user.authorized_user.id]
  grant_strings = ["ids=*;type=*;actions=*"]
} 

resource "boundary_role" "authorized_project_role" {
  name          = "authorized_project_role"
  description   = "Authorized Project Role"
  scope_id      = boundary_scope.project.id
  principal_ids = [boundary_user.authorized_user.id]
  grant_strings = ["ids=*;type=*;actions=*"]
}

There are two new grant strings in the example above:

"ids=*;type=*;actions=read" This grant ensures that the user can read all resources in the assigned scope. "ids=*;type=*;actions=*" This grant ensures that the user can perform all actions in a scope, essentially granting them admin permissions in that scope.

Configure the web target

Now that your test users exist, set up the web target. This example assumes the web target's host has a sample web application running on port 443 that the authorized user should have access to when connected through Boundary.

Create a TCP target for the web server. This example assumes port 443 for HTTPS.

Select Targets under Project Actions.
Click New Target.
Complete the following fields:
- Name: (Required) A name for identification purposes. The name must be unique.
- Description: (Optional) An optional description of the target for identification purposes.
- Type: (Required) Select TCP to create a TCP target.
- Target Address (Optional) If you are not using host catalogs and host sets, you can enter a target address instead to map the target to a single address. This must be a valid IP address or DNS name.
- Default Port (Required) The default port on which to connect, such as 443.
- Aliases (Optional) A globally-scoped unique identifier for the target, which makes the target easier to connect to using the CLI or transparent sessions. If you create an alias, click Add to assign it.
Click Save.

Create a TCP target for the web server. This example assumes port 443 for HTTPS.

Use the following command to create a TCP target named test-example-web-server with an alias test.example.com, a direct target address of 10.0.0.30 and a default connection port of 443:
```
$ boundary targets create tcp \
  -scope-id $BOUNDARY_PROJECT_ID \
  -name "test-example-web-server" \
  -with-alias-value "test.example.com" \
  -address "10.0.0.30" \
  -default-port 443
```
You must provide the scope-id field when you create a target.
Refer to the targets domain model documentation for more fields that you can use when you create targets, and the targets create command for all the CLI options.

Create a TCP target for the web server. This example assumes port 443 for HTTPS.

resource "boundary_target" "example" {
  name         = "test-example-web-server"
  description  = "Apache web server for test.example.com"
  type         = "tcp"
  address      = "10.0.0.30"
  default_port = "443"
  scope_id     = boundary_scope.project.id
}

You can create an alias if useful for your chosen connection workflow.

resource "boundary_alias_target" "test.example.com" {
  name                      = "test-example-web-server"
  description               = "Target alias for test-example-web-server"
  scope_id                  = "global"
  value                     = "test.example.com"
  destination_id            = boundary_target.example.id
}

Next steps

For an in-depth example of configuring HTTPS web targets, refer to the Secure remote access to private HTTPS targets with HashiCorp Boundary article on HashiCorp's blog.

To learn how to connect to a target, refer to Connection workflows.

To use target aliases to connect to targets:

Create a target alias
Connect to a target using an alias
After you set up a target alias, you can optionally Configure transparent sessions for end users. ^HCP/ENT

Create a web TCP target

Configure a brokered application credential

Example

Configure users and grants

Create the unauthorized and authorized users:

Assign minimal permissions to the unauthorized user in the global scope:

Assign read permissions to the authorized user in the global scope:

Assign full access permissions for the authorized user in the org scope:

Assign full access permissions for the authorized user in the project scope:

Configure the web target

Next steps

Assign minimal permissions to the unauthorized user in the `global` scope:

Assign read permissions to the authorized user in the `global` scope: