Worker concepts doc (#3487)

* Worker concepts doc

* Apply suggestions from code review

* Apply suggestions from code review

Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
Co-authored-by: Irena Rindos <irenarindos@users.noreply.github.com>

* Apply suggestions from code review

* Update website/content/docs/concepts/workers.mdx

* docs: Minor copy edits, clean up Markdown

* doc: Omit parentheses

---------

Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
Co-authored-by: Irena Rindos <irenarindos@users.noreply.github.com>

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 <sup>HCP/ENT</sup>
+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.
+
+<Tip>
+“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.
+</Tip>
+
+![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)

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"