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. They 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 authorizing and authenticating workers, refer to 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:

• Proxying target connections
• Proxying Vault connections
• Proxying multi-hop sessions

Workers proxying target connections

There are three network connectivity requirements for workers that proxy connections to targets:

1. Outbound access to an existing trusted Boundary control point using port 9202 (either another trusted worker or the Boundary control plane, or in other words, the cluster url)
2. Outbound access to the target
3. 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:

1. Outbound access to an existing trusted Boundary control point (either another trusted worker or the Boundary control plane, ie the origin url)
2. 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:

1. Ingress worker - An ingress worker is a worker that is accessible by the client. The client initiates the connection to the ingress worker.
2. 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.
3. 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 on port 9202
• 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.