워커 개요(Overview of workers)

워커는 주로 프라이빗 대상에 접근할 수 있게 해주는 Boundary 세션의 네트워크 프록시로 쓰여요. 프라이빗 네트워크를 공개에 노출하거나 사용자에게 프라이빗 네트워크 전체에 대한 접근을 주는 대신, 워커가 사용자와 대상 사이에 직접 네트워크 터널을 만들어 줍니다.

출처: HashiCorp Boundary docs

본문

워커는 컨테이너나 가상 머신에서 실행할 수 있는 서비스예요. 대상에 접근을 제공할 수 있도록 네트워크 안에 전략적으로 배포해야 합니다. 모든 Boundary 에디션에서 워커는 완전히 자체 관리되며 어디든 배포할 수 있어요. HCP Boundary에서는 HCP 관리형 워커가 클러스터와 함께 자동 배포됩니다.

Boundary의 모든 워커는 인증서와 암호화 키로 자신을 식별하고 전송 중인 데이터를 보호해요. 필요에 맞게 컨트롤러 주도(controller-led), 워커 주도(worker-led), 외부 KMS 워크플로로 워커를 등록할 수 있습니다.

워커 주도 또는 컨트롤러 주도 방식으로 등록하는 워커는 API 호출로 시스템에 등록해야 해요. 이 워커들은 현재 자격 증명 집합을 저장할 온디스크 스토리지가 필요해요. 외부 KMS를 사용하는 워커는 인증 후 자동 등록되므로, KMS는 자동 스케일링에 쓰기 쉬운 메커니즘이에요. KMS 등록은 워커가 자격 증명을 로컬에 저장할 필요가 없습니다.

워커 배포

어떤 Boundary 에디션을 실행하든 워커 배포는 같은 순서를 따릅니다:

리스너(listener), 업스트림(upstream), 태그를 정의하는 워커 구성 파일을 만들어요.
워커를 시작하고 업스트림에 도달하는지 확인해요.
워크플로에 맞는 방법으로 워커를 컨트롤러에 등록해요.
워커 태그를 추가하고 워커 필터를 구성해 워커가 프록시할 세션을 제어해요. 워커 태그는 워커 구성 파일을 만들 때나 배포 후에 추가할 수 있어요.

워커가 실행된 뒤에는 수명 주기 동안 수행하는 운영 작업에 대해서는 "워커 관리(Manage workers)"를, 예상대로 동작하지 않을 때는 "워커 문제 해결(Troubleshoot workers)"을 참고하세요.

이 섹션의 페이지들은 개별 워커 하나를 구성하고 운영하는 방법을 다룹니다. 전체 환경이나 워커 플릿(fleet)을 배포하려면 다음 주제를 참고하세요.

자체 관리 배포 절차(환경 파일, KMS 키 준비, systemd 포함)는 워커 배포(Deploy workers) 참고
Kubernetes에서 워커를 실행하려면 Helm 차트로 워커 배포(Deploy workers using a Helm chart) 참고
하드웨어 규모 산정과 네트워크 연결 요건은 시스템 요구사항(System requirements) 참고

세션 녹화(Session recording)

세션 녹화에는 로컬 및 원격 스토리지에 접근할 수 있는 워커가 최소 하나 필요해요. 세션 녹화에 쓰는 워커는 진행 중인 세션 녹화를 저장할, recording_storage_path로 정의된 접근 가능한 디렉터리가 필요해요. 세션이 종료되면 로컬 세션 녹화가 원격 스토리지로 이동하고 로컬에서는 삭제됩니다.

recording_storage_minimum_available_capacity 값은 워커가 세션 녹화 작업을 수행하는 데 필요한 최소 스토리지 공간을 결정해요. 워커가 이 저장 임계값 이하이면 Boundary는 그 워커를 세션 녹화나 녹화 재생에 사용하지 않습니다.

개발 예시:

worker {
  auth_storage_path = "/var/lib/boundary"
  initial_upstreams = ["10.0.0.1"]

  recording_storage_path = "/local/storage/directory"
  recording_storage_minimum_available_capacity = "500MB"
}

멀티홉 세션(Multi-hop sessions)

멀티홉 세션과 Vault 프라이빗 접근을 포함한 멀티홉 기능은 세션 또는 Vault 자격 증명 요청이 워커 하나 이상을 거쳐 갈 때를 말해요. 멀티홉 기능을 활성화하려면 워커 두 개 이상을 어떤 구성으로든 서로 연결해야 합니다. 멀티홉 세션 구성에서 허용되는 워커 수에는 제한이 없어요.

멀티홉 맥락에서 "업스트림(upstream)"과 "다운스트림(downstream)" 노드로 생각하면 좋아요. 컨트롤러를 멀티홉 체인의 "최상위" 노드로 본다면, 어떤 노드에 연결된 워커는 그 노드의 "다운스트림"이에요. 노드가 연결하는 워커나 컨트롤러가 그 노드의 "업스트림"이죠. 예를 들어 아래 그림에서 Worker 2의 업스트림은 Worker 1이고, 다운스트림은 Worker 3이에요.

인바운드 네트워크 트래픽이 허용되지 않는 시나리오에서도 멀티홉 워커를 배포할 수 있어요. 프라이빗 네트워크의 워커가 업스트림 워커에 아웃바운드 통신을 보내고, 세션을 수립하기 위해 리버스 프록시를 만들 수 있기 때문이죠.

멀티홉 워커로 대상 워커 필터를 구성하면 대상으로 가는 세션 트래픽의 인그레스와 이그레스를 처리할 워커를 세밀하게 제어할 수 있어요. 인그레스 워커 필터는 세션을 시작하는 데 사용할 워커를 지정하고, 이그레스 워커 필터는 대상에 접근하는 데 사용할 워커를 지정합니다.

공통 워커 파라미터

다음 필드는 모든 등록 메커니즘에 적용돼요.

worker {
  public_addr = "5.1.23.198"

  # 세션 녹화가 활성화된 경우 필요한 로컬 저장 경로
  recording_storage_path = "tmp/boundary/"

  # 세션 녹화가 활성화된 경우 로컬 저장 경로에 필요한 최소 가용 디스크 공간
  recording_storage_minimum_available_capacity = "500MB"

  # hcp_boundary_cluster_id와 상호 배타적
  initial_upstreams = [
    "10.0.0.1",
    "10.0.0.2",
  ]

  tags {
    type   = ["prod", "webservers"]
    region = ["us-east-1"]
  }

  # HCP Boundary 전용
  # hcp_boundary_cluster_id = "....."
}

public_addr - 클라이언트가 프록시를 위해 워커에 도달할 수 있는 공용 호스트 또는 IP 주소(선택적으로 포트)를 지정해요. 기본적으로 프록시 용도로 표시된 리스너의 주소를 사용합니다. 이는 Amazon EIP처럼 호스트의 NIC에 공개적으로 접근 가능한 IP를 직접 바인딩하지 않는 클라우드 환경에 유용해요. self-managed 워커가 업스트림 HCP 관리형 워커에 연결하는 멀티홉 구성에서는 이 파라미터를 생략해야 해요. 이 값은 다음 중 하나를 참조할 수 있어요: 직접 주소 문자열, 디스크의 파일에서 주소를 읽기(file://), 환경 변수에서 주소를 읽기(env://)
initial_upstreams - Boundary 클러스터에 도달하기 위한 호스트/IP 주소 목록(선택적으로 포트). 포트를 지정하지 않으면 기본값 :9201을 사용해요. 이 값은 주소가 있는 직접 접근 문자열 배열이거나, 디스크의 파일(file://)에서 읽거나 환경 변수(env://)에서 읽을 수 있어요. 환경 변수나 파일을 사용할 때는 내용이 JSON 배열 형식이어야 해요: ["127.0.0.1", "192.168.0.1", "10.0.0.1"]. HCP Boundary에 연결하는 self-managed 워커는 HCP 관리형 워커를 인그레스 워커로 구성하지 않는 한 initial_upstreams 대신 hcp_boundary_cluster_id 파라미터가 필요해요. initial_upstreams와 hcp_boundary_cluster_id를 둘 다 구성하면 워커 구성이 실패합니다.
hcp_boundary_cluster_id - 워커 주도 또는 컨트롤러 주도 등록을 사용하는 워커가 initial_upstreams를 지정하는 대신 HCP Boundary 클러스터에 연결하도록 구성하는 데 필요한 문자열이에요. 이 파라미터는 worker-led 또는 controller-led 등록 방식을 사용하는 워커와 HCP Boundary에 직접 연결된 워커에만 유효합니다.
ssh_known_hosts_path - 워커가 SSH 대상의 SSH 호스트 키를 검증하는 데 사용하는 known_hosts 파일 경로를 지정해요. 경로는 이미 존재해야 해요. 경로를 제공하지 않으면 워커는 호스트 키 검증을 건너뜁니다. SIGHUP 시 known_hosts 파일이 다시 파싱되고 새 값이 사용돼요.
recording_storage_path - 녹화된 세션을 위한 로컬 스토리지 경로예요. Boundary는 진행 중인 세션 녹화를 로컬 스토리지에 저장해요. 세션이 완료되면 로컬 세션 녹화를 원격 스토리지로 이동하고 로컬 복사본을 삭제합니다.
recording_storage_minimum_available_capacity - 워커의 로컬 스토리지 상태를 정의하는, 바이트 단위로 측정된 값이에요. Boundary는 이 값과 recording_storage_path에서 찾은 가용 로컬 디스크 공간을 비교해 워커가 세션 녹화 작업을 수행할 수 있는지 판단해요. 지원되는 접미사는 kb, kib, mb, mib, gb, gib, tb, tib이며 대소문자를 구분하지 않아요. 예: 2GB, 2gb, 2GiB, 2gib. recording_storage_minimum_available_capacity에 따른 가능한 저장 상태는 다음과 같아요.
- Available - 워커가 임계값 이상의 스토리지를 보유해 세션 녹화가 활성화된 세션을 프록시할 수 있어요.
- Low storage - 워커가 임계값 아래의 스토리지를 가짐. 기존 세션은 중단 없이 계속되지만, 세션 녹화가 활성화된 새 세션 프록시는 막아요. 워커는 새 세션을 녹화하거나 기존 녹화를 재생할 수 없어요.
- Critically low storage - 워커가 저장 임계값의 절반 아래로 떨어짐. 세션 녹화가 있는 기존 세션을 강제로 종료해요. 워커는 새 세션을 녹화하거나 기존 녹화를 재생할 수 없어요.
- Out of storage - 워커가 로컬 디스크 공간이 바닥남. 새 세션을 녹화하거나 기존 녹화를 재생할 수 없어요. 워커가 복구 불가능한 상태에 들어가므로 관리자가 개입해 문제를 해결해야 해요.
- Not configured - 워커가 구성된 로컬 저장 경로가 없음.
- Unknown - 워커가 이 기본 로컬 저장 상태로 시작됨. 워커의 로컬 저장 상태가 아직 알려지지 않았음을 나타내요.
tags - 값이 문자열 배열인 키-값 쌍의 맵이에요. 주로 워커 태그를 통해 워커가 프록시할 수 있는 대상을 필터링하는 데 쓰여요. SIGHUP 시 여기에 설정된 태그가 다시 파싱되고 새 값이 사용됩니다. 디스크의 파일(file://) 또는 환경 변수(env://)를 참조하는 문자열일 수도 있어요.

완전한 구성 예시

listener "tcp" {
  purpose   = "proxy"
  tls_disable = true
  address   = "127.0.0.1"
}

worker {
  # worker-led 또는 controller-led 등록을 가정한 워커 스토리지 경로. 워커마다 고유해야 함
  auth_storage_path = "/boundary/demo-worker-1"

  # 세션 녹화가 활성화된 경우 필요한 로컬 저장 경로
  recording_storage_path = "tmp/boundary/"

  # 세션 녹화가 활성화된 경우 로컬 저장 경로에 필요한 최소 가용 디스크 공간
  recording_storage_minimum_available_capacity = "500MB"

  # 워커는 보통 :9201에서 업스트림에 도달해야 함
  initial_upstreams = [
    "10.0.0.1",
    "10.0.0.2",
    "10.0.0.3",
  ]

  public_addr = "myhost.mycompany.com"

  tags {
    type   = ["prod", "webservers"]
    region = ["us-east-1"]
  }
}

# 다음 KMS 구성은 예시일 뿐입니다
# 프로덕션 설치에는 AWS KMS 같은 프로덕션 KMS를 사용하세요
kms "aead" {
  purpose   = "worker-auth-storage"
  aead_type = "aes-gcm"
  key       = "X+IJMVT6OnsrIR6G/9OTcJSX+lM9FSPN"
  key_id    = "worker-auth-storage"
}

튜토리얼

워커 관리, 멀티홉 세션 구성, 워커 인지 대상 만들기를 연습하려면 워커 관리 튜토리얼을 참고하세요. HCP Boundary로 워커를 등록하고 관리하는 방법은 self-managed 워커 등록 튜토리얼을, 멀티홉 세션 구성은 HCP Boundary 멀티홉 세션 관리 튜토리얼을 참고하세요.

더 알아보기 (Learn more)

워커가 Boundary 아키텍처에 어떻게 들어맞는지는 워커 개념(Workers concept) 주제를 참고하세요. 필터 구문과 모범 사례는 리소스 필터링 및 나열(Filtering and listing resources)을 참고하세요.

워커를 구성하고, 시작하고, 등록하려면 다음 주제를 참고하세요.

워커 구성 만들기(Create the worker configuration)
워커 시작 및 검증(Start and verify a worker)
워커 등록(Register workers): 컨트롤러 주도 방식 등록, 워커 주도 방식 등록, 외부 KMS 등록
워커 관리(Manage workers)
워커 문제 해결(Troubleshoot workers)

특정 애플리케이션이나 워크플로를 위한 워커 구성에 대해서는 다음 주제를 참고하세요.

멀티홉 세션 개요: Boundary Enterprise용 멀티홉 세션 구성, HCP Boundary용 멀티홉 세션 구성, 다운스트림 워커 인증
세션 녹화 개요, 세션 녹화용 워커 구성
Vault 접근용 워커 구성
클라우드 공급자의 동적 호스트 발견용 워커 구성
워커를 통한 트래픽 라우팅(Route traffic through a worker)
워커 필터 구성(Configure a worker filter)
SSH 호스트 신원 검증(Verify SSH host identity)
HCP Boundary용 self-managed 워커 구성

워커 모니터링과 보안에 대해서는 다음 주제를 참고하세요.

워커가 업스트림에 도달할 수 있는지 확인하는 Boundary 상태 엔드포인트
Boundary가 Prometheus에 내보내는 워커 메트릭(Boundary metrics)
워커가 전송 중 데이터를 보호하는 데 쓰는 인증서와 키(Boundary의 TLS)
워커가 쓰는 KMS 키(Data encryption in Boundary)