* docs: Add connection workflow docs * docs: Update HCP connect to target topic * docs: Update Overview topic and nav * docs: Break out exec flag topic * docs: Updates to connect helpers topic * docs: Update exec flag and proxycommand topics * docs: Fix broken link * docs: Update meta content and get started topics * docs: Redirect deleted proxycommand topic * docs: Add links for HCP and self-managed tutorials * docs: Add multi-hop * adds CodeTabs and windows instructions * Update website/content/docs/concepts/connection-workflows/workflow-ssh-proxycommand.mdx Co-authored-by: Robin Beck <stellarsquall@users.noreply.github.com> * removes windows workflow --------- Co-authored-by: stellarsquall <stellarsquall@protonmail.ch> Co-authored-by: Robin Beck <stellarsquall@users.noreply.github.com>
68 lines
4.1 KiB
Plaintext
68 lines
4.1 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Connection workflows
|
|
description: |-
|
|
Workflows that you can use to connect to targets. Learn how connect helpers, the `-exec` flag, and SSH ProxyCommand can help facilitate connections to targets.
|
|
---
|
|
|
|
# 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`](/boundary/docs/commands/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](/boundary/tutorials/hcp-getting-started/hcp-getting-started-connect) or the [self-managed versions](/boundary/tutorials/oss-getting-started/oss-getting-started-connect) 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](/boundary/docs/concepts/connection-workflows/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](/boundary/docs/concepts/connection-workflows/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](/boundary/docs/concepts/connection-workflows/workflow-ssh-proxycommand) documentation for more information.
|
|
|
|
## Multi-hop sessions
|
|
|
|
<EnterpriseAlert product="boundary">This feature requires <a href="https://www.hashicorp.com/products/boundary">HCP Boundary or Boundary Enterprise</a></EnterpriseAlert>
|
|
|
|
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](/boundary/docs/concepts/connection-workflows/multi-hop) documentation for more information. |