| layout | page_title | description |
|---|---|---|
docs |
Workers |
Introduction to Boundary workers |
Boundary's architecture consists of three main components:
- Control plane - made up of controllers
- Data plane - made up of workers
- 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.
You can use workers in various ways depending on your needs, as follows:
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 sessions and form a chain of proxies to reach deeper into protected networks.
Workers can authenticate 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."
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 environment.
Workers can perform SSH protocol decryption for credential injection and session recording. For session recording, workers also write the recorded session contents directly to the storage bucket.
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 that Boundary can filter 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 workers report their status to controllers on a regular basis. You can view the last time a worker reported its status in the admin UI as Last Seen and in the CLI as the Last Status Time. If a worker hasn't reported status recently, it can be an indication of an unhealthy worker.
You can query the worker health endpoint to determine the health of a worker. The endpoint returns the worker state, active session count, and connection state of the worker. For more information, refer to the health endpoints documentation.
This feature requires HCP Boundary or Boundary Enterprise
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 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.
Refer to the multi-hop sessions documentation for more information.
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: