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. The following is a breakdown for 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:

1. Outbound access to an existing trusted Boundary control point (Boundary control plane, or 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.