HCP Boundary용 멀티홉 세션 구성
HCP Boundary용 멀티홉 세션 구성 (Configure multi-hop sessions for HCP Boundary)
많은 조직이 네트워크로 들어오는 모든 인바운드 트래픽을 금지하는 엄격한 네트워크 정책을 갖고 있어요. 이런 환경에서는 HCP 관리형 worker를 ingress worker로 사용할 수 있습니다. 사설 네트워크 안의 셀프 매니지드 worker가 HCP 관리형 worker로 아웃바운드 연결을 시작하면, Boundary가 양방향으로 사용하는 지속 연결이 만들어집니다.
최종 사용자가 타깃에 연결하면 세션은 다음과 같은 체인을 거쳐요:
- Boundary 클라이언트가 HCP 관리형 worker(ingress worker 역할)에 연결
- HCP 관리형 worker가 셀프 매니지드 worker(멀티홉 배포에서 egress worker 또는 intermediate worker 역할)에 연결
- egress worker가 타깃에 연결
사설 네트워크 안쪽까지 더 깊이 도달해야 한다면, ingress와 egress worker 사이에 intermediate worker를 추가할 수 있어요. worker 역할에 대한 자세한 내용은 멀티홉 세션을 참고하세요.
본문
사전 요구 사항
HCP Boundary용 멀티홉 세션을 구성하기 전에 다음이 필요해요:
- HCP Boundary 클러스터와 해당 URL의 클러스터 ID
- 사설 네트워크 안에 Boundary Enterprise 바이너리가 설치된 호스트가 하나 이상 (Boundary 설치 참고)
- 셀프 매니지드 worker에서 HCP 관리형 worker로의
9202포트 아웃바운드 네트워크 접근 global스코프에서 worker를 등록할 권한
인바운드 네트워크 규칙은 필요 없어요. 셀프 매니지드 worker가 HCP 관리형 worker로 연결을 시작하니까요.
HCP 관리형 worker로의 아웃바운드 네트워크 트래픽 허용
일부 조직은 모든 아웃바운드 트래픽에 대해 방화벽 규칙에 명시적인 목적지 주소를 요구합니다. 이런 경우에는 HCP 관리형 worker의 FQDN(정규화된 도메인 이름)을 사용하면 돼요:
<cluster_uuid>.proxy.boundary.hashicorp.cloud
cluster_uuid 값은 HCP Boundary 클러스터 ID로, HCP Boundary 클러스터의 URL에서 찾을 수 있어요. Boundary 클러스터 ID는 Boundary 주소에서 파생됩니다. 예를 들어 클러스터 URL이 다음과 같다면:
https://abcd1234-e567-f890-1ab2-cde345f6g789.boundary.hashicorp.cloud
클러스터 ID는 abcd1234-e567-f890-1ab2-cde345f6g789예요.
worker 구성
HCP Boundary 멀티홉 체인은 ingress에 HCP 관리형 worker를 사용하고, egress에 셀프 매니지드 worker를 최소 한 개 사용합니다. 다음 절에서 각 worker의 역할과 필요한 구성을 설명할게요.
Ingress workers
HCP Boundary는 클러스터와 함께 HCP 관리형 worker를 배포하고, 이 worker들이 ingress worker 역할을 해요. 직접 만들거나 구성할 필요가 없습니다.
Egress worker 구성
HCP 관리형 worker에 연결하고 타깃에 도달하는 셀프 매니지드 worker를 구성해요. 다음 파라미터를 설정합니다:
hcp_boundary_cluster_id— HCP Boundary 클러스터 ID. 이 파라미터는worker스탠자 바깥, 파일의 최상위 레벨에 설정해요.public_addr파라미터는 생략합니다. 셀프 매니지드 worker가 HCP 관리형 worker로 연결을 시작하므로, 도달 가능한 주소가 필요 없어요.initial_upstreams파라미터는 생략합니다.hcp_boundary_cluster_id파라미터가 이미 업스트림으로 HCP 관리형 worker를 식별하니까요.worker스탠자에 worker 태그를 포함시킵니다. 이 태그로 각 타깃의 멀티홉 경로를 선택하게 돼요.
/etc/boundary.d/egress-worker.hcl:
hcp_boundary_cluster_id = "abcd1234-e567-f890-1ab2-cde345f6g789"
listener "tcp" {
address = "0.0.0.0:9202"
purpose = "proxy"
}
worker {
auth_storage_path = "/var/lib/boundary"
tags {
type = ["multihop", "egress"]
}
}
Warning — 같은 구성 파일에
hcp_boundary_cluster_id와initial_upstreams를 둘 다 설정하지 마세요. 두 파라미터는 상호 배타적이고, 둘 다 두면 worker가 시작에 실패해요:Initial upstreams and HCPB cluster ID are mutually exclusive fields
Intermediate worker 구성
타깃이 사설 네트워크 안쪽에 더 깊이 있다면, HCP Boundary에 연결하는 셀프 매니지드 worker와 타깃에 도달하는 worker 사이에 intermediate worker를 추가할 수 있어요.
HCP 관리형 worker에 연결하는 worker가 hcp_boundary_cluster_id를 설정하는 worker예요. 그 아래의 각 worker는 initial_upstreams를 위 worker의 주소로 설정하고 hcp_boundary_cluster_id는 생략합니다.
intermediate와 egress worker 구성은 Boundary Enterprise용 멀티홉 세션 구성을 참고하세요. 그 worker들은 HCP Boundary가 아니라 업스트림 worker에 연결하므로, 셀프 매니지드 배포에서 쓰는 것과 같은 구성을 사용해요.
worker 시작 및 등록
호스트에서 worker를 시작해요:
$ boundary server -config=/etc/boundary.d/egress-worker.hcl
systemd나 컨테이너에서 worker를 실행하려면 worker 시작 및 검증을 참고하세요.
worker 기반(worker-led) 또는 컨트롤러 기반(controller-led) 방식으로 worker를 HCP Boundary 클러스터에 등록합니다. 외부 KMS 방식과 hcp_boundary_cluster_id 파라미터는 함께 사용할 수 없어요. 또, HCP 관리형 worker에 직접 연결하는 worker에는 worker-auth KMS 키를 구성할 수도 없습니다.
intermediate worker를 추가한다면, 체인의 맨 위부터 순서대로 시작하고 등록하세요. 다운스트림 worker는 업스트림이 실행되고 인증되기 전까지 연결할 수 없어요.
체인 검증
다음 명령으로 컨트롤러에 등록된 worker 목록을 확인할 수 있어요:
$ boundary workers list
Boundary는 등록된 각 worker, 그 주소, 릴리스 버전을 반환합니다:
Worker information:
ID: w_UJ3Qq63Jx0
Version: 1
Address: 10.0.0.10:9202
ReleaseVersion: Boundary v1.0.0+ent
Last Status Time: Fri, 07 Aug 2026 19:45:12 UTC
Authorized Actions:
no-op
read
update
delete
add-worker-tags
set-worker-tags
remove-worker-tags
Last Status Time 이 최근 값이면 worker가 업스트림에 연결되어 상태를 보고하고 있다는 뜻이에요.
특정 worker의 상세 정보를 보려면 다음 명령을 사용해요:
$ boundary workers read -id w_UJ3Qq63Jx0
Boundary는 worker의 구성 태그, 저장 상태, 연결된 다운스트림 worker를 반환합니다:
Worker information:
Active Connection Count: 0
Address: 10.0.0.10:9202
Created Time: Fri, 07 Aug 2026 13:44:30 MDT
ID: w_UJ3Qq63Jx0
Last Status Time: 2026-08-07 19:45:22.616245 +0000 UTC
Local Storage State: not configured
Release Version: Boundary v1.0.0+ent
Type: pki
Updated Time: Fri, 07 Aug 2026 13:45:22 MDT
Version: 1
Scope:
ID: global
Name: global
Type: global
Tags:
Configuration:
type: ["worker1" "ingress"]
Canonical:
type: ["worker1" "ingress"]
Authorized Actions:
no-op
read
update
delete
add-worker-tags
set-worker-tags
remove-worker-tags
출력에는 worker 상태를 나타내는 다음 필드가 들어 있어요:
Last Status Time— worker가 컨트롤러에 상태를 마지막으로 보고한 시간Local Storage State— worker 로컬 저장소의 상태. 세션 녹화용으로 worker를 구성하지 않았다면 값은not configured예요.Release Version— worker가 실행 중인 Boundary 버전Tags—Configuration태그는 worker 구성 파일에서 가져옵니다.Canonical태그는 구성 태그와 API로 추가한 태그를 모두 포함해요.
셀프 매니지드 worker가 두 개 이상인 체인에서는 Directly Connected Downstream Workers 필드로 체인 모양을 확인할 수 있어요. 각 worker를 차례로 읽어서 아래 worker가 목록에 있는지 확인하세요. 체인 끝에 있는 worker에는 다운스트림 worker가 없습니다.
체인을 통한 타깃 트래픽 라우팅
HCP 관리형 worker를 통해 트래픽을 라우팅하려면, 각 타깃에 egress worker 필터를 설정해서 셀프 매니지드 worker 구성 파일에 설정한 태그와 일치시켜요. HCP 관리형 worker가 이미 ingress worker 역할을 하므로 ingress worker 필터는 설정할 필요가 없어요.
CLI에서 셀프 매니지드 worker의 태그와 일치하는 egress worker 필터를 설정해요:
$ boundary targets update tcp -id ttcp_uPVxp2NGiD \
-egress-worker-filter='"egress" in "/tags/type"'
다음 Terraform 구성을 적용해요:
resource "boundary_target" "private_web" {
type = "tcp"
name = "private-web"
description = "Multi-hop target"
scope_id = boundary_scope.project.id
default_port = 443
egress_worker_filter = "\"egress\" in \"/tags/type\""
}
더 많은 필터 예시는 worker 필터 구성을 참고하세요.
연결 테스트
세션이 체인을 제대로 통과하는지 확인하려면 타깃에 연결해요:
$ boundary connect -target-id ttcp_uPVxp2NGiD
필터와 일치하는 worker가 없어서 세션이 실패한다면 worker 문제 해결을 참고하세요.
더 알아보기 (Learn more)
체인을 구성한 뒤에는 다음을 할 수 있어요:
- 타깃에 연결하는 worker에서 SSH 호스트 ID 검증
- worker 관리로 구성 리로드 또는 세션 드레인
- 설치 및 용량 지침을 위한 HCP Boundary용 셀프 매니지드 worker 구성