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.
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.”
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.
In multi-hop scenarios, there are typically three types of workers:
- Ingress worker - An ingress worker is a worker that is accessible by the client. The client initiates the connection to the ingress worker.
- 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.
- 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.
After the persistent connection chain is established between the workers, when you attempt to connect to a target host, you are automatically proxied from:
- Boundary client to ingress worker
- Ingress worker to intermediary worker, where applicable
- Ingress worker to egress worker
- Egress worker to desired target
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: