Self-managed worker operations
Self-managed workers allow Boundary users to securely connect to private endpoints without exposing their organizations' networks to the public, or to HashiCorp-managed resources. The self-managed worker nodes proxy any session activity.
Self-managed workers use public key infrastructure (PKI) for authentication. PKI workers authenticate to Boundary using a certificate-based method that allows you to deploy workers without using a shared key management service (KMS). For more information about PKI workers, refer to PKI Worker Configuration.
This page outlines operational guidance for running self-managed workers with HCP Boundary in production.
Network requirements for Boundary workers
Boundary workers proxy connections to remote endpoints. Workers can either proxy connections to target endpoints, proxy connections from Boundary control plane traffic to private Vault environments and other peer services, or both.
In multi-hop sessions, you can use a chain of workers to proxy connections to targets. Multi-hop configurations are helpful in situations where inbound traffic to the target's network is not allowed. A worker in a private network sends outbound communication to its upstream worker, and can then create reverse proxies to establish sessions.
The following sections describe worker network connectivity requirements depending on what the worker is used for:
Workers proxying target connections
There are three network connectivity requirements for workers that proxy connections to targets:
- Outbound access to an existing trusted Boundary control point (either another trusted worker or the Boundary control plane, or in other words, the cluster url)
- Outbound access to the target
- Inbound access from client trying to establish the session
The third requirement does not require exposure to the public internet, just inbound access from clients. Consider the case of Boundary being accessed by clients from a private corporate network (not public internet) to facilitate connections to a separate private datacenter network:
- The worker would need outbound connectivity to a trusted Boundary control point (either another trusted worker or the Boundary control plane, ie the origin url)
- The worker would need outbound connectivity to the host network (the datacenter network or cloud VPC) for which it can make outbound (worker->host) calls to hosts
- The worker would need to allow inbound (client->worker) connections from the client's network (this would be the corporate network, not public internet in this scenario)
Workers proxying Vault connections
When proxying connections to private Vault clusters, workers have two network connectivity requirements:
- Outbound access to an existing trusted Boundary control point (either another trusted worker or the Boundary control plane, ie the origin url)
- Outbound access to the destination private Vault
The following diagram illustrates worker connectivity directionality based on the requirements above for HCP Boundary with self-managed workers.
Workers proxying multi-hop sessions
In multi-hop sessions, the workers can serve three different functions:
- 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.
The functions are general ways to describe how workers interact with resources. A worker can perform more than one function, if it meets the requirements. For more information, refer to Multi-hop sessions.
When you proxy connections to targets in multi-hop sessions, the ingress, intermediary, and egress workers have the following additional requirements.
Ingress workers
Similar to single layer workers, ingress workers in a multi-hop session must have:
- Outbound access to the Boundary control plane
- Inbound access from clients
Intermediary workers
In a multi-hop session, intermediary workers require:
Outbound access to an upstream worker
The upstream worker may be an ingress worker or another intermediary worker. Any upstream, intermediary worker must eventually connect to an ingress worker using trusted intermediary workers.
Inbound access from a downstream worker
The downstream worker may be an egress worker or another downstream worker. Any downstream, intermediary worker must eventually connect to an egress worker using trusted intermediary workers.
Egress workers
In a multi-hop session, the egress workers on the target's side require:
Outbound access to an upstream worker
Outbound access to the destination host
Inbound session connections from clients reach the egress worker via reverse proxy with the ingress worker as initiated from the egress worker.
The following diagram illustrates the direction of worker connectivity in a a multi-hop session. The arrows show the direction in which network communication is initiated. The white lines represent the Boundary cluster's control plane traffic. The red lines represent the direction of a user's session traffic.
