Connection workflows

This topic provides an overview of the possible workflows you may use to connect to targets with Boundary.

Boundary connect

When you run the boundary connect command against a target, Boundary establishes a local authenticated proxy to the address on the target's default port. The boundary connect command has a number of useful options, such as -listen-port which lets you choose the port on which the command listens for an incoming connection. Refer to the boundary connect documentation for a list of the available options and usage examples.

To practice using the boundary connect command in a development environment, refer to the Connect to your first target tutorial for either HCP Boundary or the self-managed versions of Boundary.

Connect helpers

Boundary features connect helpers that assist with making connections to targets using certain protocols. Connect helpers automatically accept key prompts for you. They are supported for the following connection types:

• HTTP
• Kubernetes
• PostgreSQL
• RDP
• SSH

Refer to the Connect helpers documentation for more information.

Exec flag

In addition to the built-in connect helpers, boundary connect can accommodate executing clients even when there is no built-in support for a specific client using the -exec flag. The -exec flag lets you wrap Boundary TCP sessions in your preferred client. You can use this flag to create an authenticated proxy to almost anything.

Refer to the Exec flag documentation for more information.

SSH ProxyCommand

The most common pattern for using Boundary to SSH is with the built-in boundary connect ssh command. However, there are more idiomatic approaches that can be employed to make Boundary transparent to users, and at the same time simplify common developer and operator workflows. Using ProxyCommand to execute a proxy when invoking the SSH client is a common practice.

SSH ProxyCommand lets you proxy an SSH connection to a target according to a configuration file that you create. You can configure the file to connect to the target ID or the target domain.

Refer to the SSH ProxyCommand documentation for more information.

Multi-hop sessions

Most organizations want to provide access to infrastructure without exposing private networks. Many organizations also have complex network topologies requiring inbound traffic to route through multiple network enclaves to reach the target system. Multi-hop sessions allow you to chain together two or more workers across multiple networks to form reverse proxy connections between the user and the target, even in complex networks with strict outbound-only policies.

You can deploy multi-hop workers in scenarios where inbound network traffic is not allowed. A worker in a private network can send outbound communication to its upstream worker, and create a reverse proxy to establish a session.

You can configure target worker filters with multi-hop workers to allow for fine-grained control on which workers handle ingress and egress for session traffic to a target. Ingress worker filters determine which workers you connect with to initiate a session, and egress worker filters determine which workers are used to access targets.

Refer to the Multi-hop sessions documentation for more information.