KMS로 다운스트림 worker 인증하기

KMS로 다운스트림 worker 인증하기 (Authenticate downstream workers with a KMS)

멀티홉 배포에서는 다운스트림 worker가 컨트롤러에 직접 연결하는 대신 업스트림 worker에 연결해요. 다운스트림 worker가 외부 KMS를 통해 등록되면, downstream-worker-auth KMS 목적을 사용해서 업스트림 worker가 이들을 인증하도록 할 수 있습니다.

이 방식을 쓰면 에지(edge) worker의 인증을 신뢰할 수 있는 업스트림 worker에 위임할 수 있어요. 컨트롤러 KMS 키를 그 환경에 배포하지 않아도 됩니다.

출처: HashiCorp Boundary docs

본문

트러스트 도메인이 동작하는 방식

Boundary는 업스트림 worker와 다운스트림 worker를 구분해요:

  • 업스트림 worker는 컨트롤러에 직접 연결하거나 다른 업스트림 worker에 연결합니다. worker-auth 목적의 KMS 키로 인증해요.
  • 다운스트림 worker는 컨트롤러에 직접 연결하는 대신 업스트림 worker에 연결합니다. 같은 KMS 메커니즘으로 인증하되, 트러스트 앵커는 컨트롤러가 아니라 업스트림 worker예요.

downstream-worker-auth 목적은 업스트림 worker에만 구성합니다. 이 구성은 업스트림 worker가 다운스트림 worker가 제시하는 토큰을 검증할 때 어떤 KMS 키를 신뢰할지 지정해요.

다운스트림 worker는 같은 키 자료를 참조하는 worker-auth KMS 블록을 사용합니다. 업스트림 worker는 그 키를 가리키는 대응하는 downstream-worker-auth 블록을 사용해요. 이 모델 덕분에:

  • worker-auth로 컨트롤러↔worker 신뢰에 KMS 키 하나를 사용할 수 있고요
  • downstream-worker-auth로 다른 KMS 키 또는 다른 KMS 백엔드를 사용해서 다운스트림 네트워크를 격리할 수 있으며
  • 컨트롤러 KMS 키를 그 환경에 노출하지 않고 에지 worker 인증을 신뢰할 수 있는 업스트림 worker에 위임할 수 있어요

예시 구성

다음 예시는 컨트롤러, 컨트롤러에 연결하는 ingress worker, 그리고 ingress worker에만 연결하는 egress worker를 보여줍니다.

컨트롤러는 worker-auth로 직접 연결하는 worker들을 인증해요 (/etc/boundary.d/controller.hcl):

kms "awskms" {
  purpose = "worker-auth"
  key_id  = "arn:aws:kms:us-east-1:111111111111:key/controller-workers"
  region  = "us-east-1"
}

controller {
  # ...
}

Ingress worker는 두 목적을 모두 구성합니다. worker-auth로 컨트롤러에 자기 자신을 인증하고, downstream-worker-auth로 자기 아래의 worker들을 인증해요 (/etc/boundary.d/ingress-worker.hcl):

worker {
  name              = "ingress-1"
  initial_upstreams = ["10.0.0.10:9201"]
  public_addr       = "ingress-1.example.internal"
}

# Authenticates the ingress worker to the controllers
kms "awskms" {
  purpose = "worker-auth"
  key_id  = "arn:aws:kms:us-east-1:111111111111:key/controller-workers"
  region  = "us-east-1"
}

# Authenticates downstream workers to the ingress worker
kms "awskms" {
  purpose = "downstream-worker-auth"
  key_id  = "arn:aws:kms:us-east-1:111111111111:key/edge-workers"
  region  = "us-east-1"
}

Egress worker는 edge 키를 사용해서 worker-auth만 구성합니다. initial_upstreams 값은 컨트롤러가 아니라 ingress worker를 가리켜요 (/etc/boundary.d/egress-worker.hcl):

worker {
  name              = "egress-1"
  initial_upstreams = ["ingress-1.example.internal:9202"]
  public_addr       = "egress-1.example.internal"
}

# Authenticates the egress worker to its upstream, ingress-1
kms "awskms" {
  purpose = "worker-auth"
  key_id  = "arn:aws:kms:us-east-1:111111111111:key/edge-workers"
  region  = "us-east-1"
}

이 토폴로지에서:

  • 컨트롤러와 ingress worker는 worker-auth 키 controller-workers를 공유해요.
  • ingress worker와 egress worker는 다른 키인 edge-workers를 공유합니다.
  • ingress worker는 두 목적을 모두 구성하므로, 컨트롤러에 대한 클라이언트 역할과 다른 worker에 대한 인증 업스트림 역할을 동시에 수행할 수 있어요.

트러스트 체인 검증

먼저 업스트림 worker를 시작하고, 그다음 다운스트림 worker를 시작하세요. 다음 명령으로 업스트림 worker가 다운스트림 worker를 인증했는지 확인할 수 있어요:

$ boundary workers read -id w_3f1IhyQfaj

Directly Connected Downstream Workers 필드는 이 업스트림을 통해 인증된 worker들을 나열합니다:

Worker information:
  Address:                   ingress-1.example.internal:9202
  ID:                        w_3f1IhyQfaj
  Name:                      ingress-1
  Release Version:           Boundary v1.0.0+ent
  Type:                      pki

  Directly Connected Downstream Workers:
    w_8WYmILuVvf

다운스트림 worker가 나타나지 않으면 로그에서 TLS 핸드셰이크 오류를 확인해 보세요. 그 오류는 다운스트림 worker의 worker-auth 키가 업스트림의 downstream-worker-auth 키와 일치하지 않는다는 뜻이에요:

(nodeenrollment.protocol.attemptFetch) error tls handshaking connection on client: remote error: tls: internal error

여러 트러스트 도메인 구성하기

단일 업스트림 worker에 downstream-worker-auth 목적의 kms 블록을 여러 개 구성할 수 있어요. Boundary는 각 키를 풀에 추가하고, 그 풀의 어떤 키에서든 파생된 토큰을 제시하는 다운스트림 worker를 수락합니다. 각 블록은 다운스트림 worker를 위한 별도의 트러스트 도메인을 나타내요.

downstream-worker-auth 목적은 KMS 목적 중에서 예외입니다. Boundary는 worker-auth 목적의 kms 블록은 하나만 허용하고, 두 개 이상 정의하면 시작에 실패해요.

다음 경우에 별도의 키를 사용하는 걸 고려해 보세요:

  • 서로 다른 네트워크/환경 — 데이터 센터 또는 클라우드 계정마다 키 하나를 구성
  • 서로 다른 민감도 수준 — 프로덕션과 비프로덕션 다운스트림 worker에 별도의 키 구성
  • 점진적 마이그레이션 — 기존 worker가 기존 키를 계속 쓰는 동안 새 키로 새 다운스트림 worker를 온라인에 올리고, 시간을 두고 기존 키를 단계적으로 제거

다운스트림 worker는 업스트림에서 downstream-worker-auth 목적으로 구성한 키 중 하나를 참조하는 worker-auth 블록을 사용해야 해요. 업스트림 worker는 알 수 없는 키에서 파생된 토큰을 제시하는 다운스트림 worker를 거부합니다.

운영 고려 사항

downstream-worker-auth를 사용하는 멀티홉 토폴로지를 설계할 때 다음 사항을 염두에 두세요:

  • 키 회전 — downstream-worker-auth 키를 회전하려면 업스트림 worker와 그 영향권에 있는 모든 다운스트림 worker에 변경을 함께 조정해야 해요. 새 키를 추가하고, worker를 마이그레이션하고, 기존 키를 제거하는 단계적 롤아웃이 다운타임을 최소화합니다.
  • 영향 범위 — downstream-worker-auth 키가 트러스트 도메인을 정의하므로, 서로 다른 환경을 별개의 키로 격리하면 키가 유출됐을 때의 영향 범위를 제한할 수 있어요.
  • KMS 백엔드 — 업스트림 worker는 worker-auth와 downstream-worker-auth에 서로 다른 KMS 백엔드를 사용할 수 있습니다. 예를 들어 컨트롤러는 온프레미스 KMS를, 에지 worker는 대상 지역의 클라우드 KMS를 쓰는 식이에요.
  • 감사 가능성 — Boundary는 worker 인증 이벤트를 이벤트 로그에 기록합니다. name 값과 worker가 사용한 KMS 키를 연관시키면, 특정 시점에 worker가 어느 트러스트 도메인에 속했는지 확인할 수 있어요.

더 알아보기 (Learn more)

자세한 내용은 다음 주제를 참고하세요: