diff --git a/website/content/docs/concepts/workers.mdx b/website/content/docs/concepts/workers.mdx new file mode 100644 index 0000000000..e9f58f1f24 --- /dev/null +++ b/website/content/docs/concepts/workers.mdx @@ -0,0 +1,87 @@ +--- +layout: docs +page_title: Workers +description: |- + Introduction to Boundary workers +--- + +# Workers +Boundary's architecture consists of three main components: +1. **Control plane** - made up of controllers +1. **Data plane** - made up of workers +1. **Client** - installed on the user's device + +**Controllers** are what users authenticate to using the client, they contain Boundary's resources and permissions. In addition, controllers also communicate with external components +such as the database, KMS, Vault, identity providers, and plugins. + +**Workers** are primarily used as network proxies for Boundary sessions, they allow you to access +private targets. Instead of exposing a private network to the public, or allowing users to have access to entire private networks, workers create a direct network +tunnel between users and targets. + +![Boundary architecture example showing workers and controllers](/img/access-model.png) + +## Capabilities +You can use workers in various ways depending on your needs, as follows: + +### Session proxying + +You can use workers to proxy sessions between clients and targets located in public or private networks. In addition, you can configure workers in +[multi-hop](#multi-hop-sessions-hcp-ent) sessions and form a chain of proxies to reach deeper into protected networks. + +### Worker authentication + +Workers can [authenticate](/boundary/docs/concepts/security/connections-tls#pki-based-worker-authentication) directly to the control plane or through an upstream worker to the control plane. Authenticating through an upstream worker is also referred to as "multi-hop worker authentication." + +### Controller proxy + +In situations where controllers need access to a private service but don't have network access to it, workers can act as a proxy for communication. This is currently +supported for controllers connecting to a [private Vault](/boundary/tutorials/credential-management/hcp-private-vault-cred-injection) +environment. + +### Protocol decryption + +Workers can perform SSH protocol decryption for [credential injection](/boundary/docs/concepts/credential-management#credential-injection-hcp-ent) and [session +recording](/boundary/docs/concepts/domain-model/session-recordings). For session recording, workers also write the recorded session contents directly to the [storage +bucket](/boundary/docs/concepts/domain-model/storage-buckets). + +## Tags +In multi-datacenter and multi-cloud operating models, patterns of dividing up controllers, workers, and targets into appropriate regions or networks is often +desired to reduce latency or comply with security standards. You can assign workers [tags](/boundary/tutorials/worker-management/target-aware-workers) that Boundary +can [filter](/boundary/docs/concepts/filtering/worker-tags) through, to find the appropriate worker to use for a session. For example, Boundary could filter to workers +with tag “A,” to connect to targets in “Network A.” + +![Boundary architecture example showing workers with tags](/img/worker-tags.png) + +## Multi-hop sessions HCP/ENT +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 in order to reach the target system. +[Multi-hop](/boundary/docs/configuration/worker#multi-hop-worker-capabilities-hcp-ent) 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. + +In multi-hop scenarios, there are typically three types of workers: +1. **Ingress worker** - An ingress worker is a worker that is accessible by the client. The client initiates the connection to the ingress worker. +1. **Intermediary worker** - An optional intermediary worker sits between ingress and egress workers as part of a multi-hop chain. There can be multiple intermediary workers as part of a multi-hop chain. +1. **Egress worker** - An egress worker is a worker that can access the target. The egress worker initiates reverse proxy connections to intermediary or ingress workers. + + +“Ingress,” “intermediary,” and “egress” are general ways to describe how the respective worker interfaces with resources, and a worker can act as more than one of those +at a time. For example in the diagram below, the intermediary worker is also an egress worker since it can access a target. + + +![Multi-hop session example showing ingress, intermediary, and egress workers](/img/concepts-multihop.png) + +After the persistent connection chain is established between the workers, when you attempt to connect to a target host, you are automatically proxied from: +1. Boundary client to ingress worker +1. Ingress worker to intermediary worker, where applicable +1. Ingress worker to egress worker +1. Egress worker to desired target + +## Deployment +Workers are services that can run on a container or virtual machine. You should deploy them strategically within networks to provide access to targets. In +all editions of Boundary, workers are fully self-managed and can be deployed anywhere. In HCP Boundary, HCP-managed workers are automatically deployed with the cluster. + +To learn more about workers and deployment, see: +* [Worker configuration](/boundary/docs/configuration/worker) +* [Recommended architecture](/boundary/docs/install-boundary/recommended-architecture) +* [Worker system requirements](/boundary/docs/install-boundary/system-requirements) +* [Worker management tutorials](/boundary/tutorials/worker-management) diff --git a/website/data/docs-nav-data.json b/website/data/docs-nav-data.json index 6fe7f00b0c..a6fc160acb 100644 --- a/website/data/docs-nav-data.json +++ b/website/data/docs-nav-data.json @@ -132,6 +132,10 @@ "title": "Overview", "path": "concepts" }, + { + "title": "Workers", + "path": "concepts/workers" + }, { "title": "Identity and access management", "path": "concepts/iam" diff --git a/website/public/img/access-model.png b/website/public/img/access-model.png new file mode 100644 index 0000000000..eada43e22a Binary files /dev/null and b/website/public/img/access-model.png differ diff --git a/website/public/img/concepts-multihop.png b/website/public/img/concepts-multihop.png new file mode 100644 index 0000000000..c7d7c4a5cc Binary files /dev/null and b/website/public/img/concepts-multihop.png differ diff --git a/website/public/img/worker-tags.png b/website/public/img/worker-tags.png new file mode 100644 index 0000000000..b73e4b48f2 Binary files /dev/null and b/website/public/img/worker-tags.png differ