Boundary 도메인 모델 개요

HashiCorp Boundary는 확장 가능한 도메인 모델을 가지고 있어요. 덕분에 관리자는 조직이 컴퓨팅 인프라를 관리하는 방식에 가장 잘 맞게 IAM(Identity and Access Management) 리소스와 대상(target) 리소스를 구성할 수 있어요. 이 개념 페이지는 스코프(scope)가 무엇이고 어떻게 동작하며 도메인 모델에서 어떤 역할을 하는지 높은 수준에서 살펴봐요. Boundary가 IAM과 대상에 대한 접근 권한 부여를 어떻게 다루는지도 함께 탐구해요. Boundary의 리소스 유형에 대한 더 자세한 내용은 Domain Model 절의 하위 페이지들을 참고하세요.

출처: HashiCorp Boundary docs

본문

HashiCorp Boundary는 확장 가능한 도메인 모델을 가지고 있어요. 관리자는 이를 통해 IAM과 대상 리소스를 조직이 컴퓨팅 인프라를 관리하는 방식에 가장 잘 맞게 구성할 수 있어요.

스코프(Scopes)

위협 모델링(threat modeling)을 수행할 때, 식별된 위험을 잠재적 폭발 반경(blast radius)과 공격 표면(attack surface)을 줄여 완화하는 것이 일반적인 관행이에요. Boundary는 보안 운영자가 이런 완화를 할 수 있도록 '스코프' 개념을 사용해요. 스코프는 리소스와 권한의 컨테이너로 볼 수 있어요. 각 스코프는 같은 레벨의 다른 스코프와 격리된 권한 경계를 가지므로, 정의된 폭발 반경을 만들어요.

아래 다이어그램은 스코프의 서로 다른 레벨 간의 관계를 보여줘요.

가장 높은 레벨의 스코프는 global 스코프예요. Boundary 관리자는 이 레벨에서 전체 비즈니스를 위한 Boundary를 구성하고 관리해요. Boundary 관리자는 하위 스코프, 인증 방법(auth method), 사용자, 그룹, 역할, 부여(grants)도 관리할 수 있어요.

중간 스코프 레벨은 **organization(조직)**이에요. 줄여서 org라고도 불러요. global의 하위 스코프죠. 조직 스코프의 구현은 유연할 수 있지만, 비즈니스 단위로 스코프를 나누는 것을 권장해요. 비즈니스 단위로 나누면 각 비즈니스 단위의 관심사가 명확히 분리돼요. 예를 들어 개발, 운영, 지원 팀을 위한 조직을 만드는 경우가 있겠죠.

가장 낮은 스코프 레벨은 **project(프로젝트)**예요. 조직의 스코프는 비즈니스 워크플로에 따라 필요한 만큼 많은 프로젝트를 가질 수 있어요. 앞선 예시를 확장하면, 개발 팀의 조직은 서로 다른 제품을 위한 프로젝트 스코프를 가질 수도 있어요.

예를 들어 다음과 같은 프로젝트 스코프를 가질 수 있어요.

Product 1
Product 2
Product 3

아이덴티티 및 접근 관리(IAM)

앞서 언급했듯이 IAM은 조직(organization)과 global 스코프 레벨에서 처리돼요. 여기서 운영자는 주체(principal)를 만들고 관리할 수 있어요. 주체는 Boundary에서 사용자(user) 또는 그룹(group)이며, 여기에 기능(capabilities)을 할당할 수 있어요.

사용자는 global 또는 조직의 스코프와 연관돼요. 접근 제어 관리를 더 잘하기 위해 사용자는 그룹에 배치될 수 있어요. 그룹은 다른 조직이나 global 스코프의 사용자를 포함할 수도 있어서, 단일 엔티티에 대해 여러 사용자를 만들 필요 없이 권한 부여를 덜 복잡하게 구현할 수 있어요.

**인증 방법(auth method)**은 인증을 위해 Boundary에서 사용하는 메커니즘이에요. 조직은 여러 인증 방법을 사용할 수 있어요. Boundary는 인증을 외부 아이덴티티 제공자(IDP) — 예: Azure Active Directory, Okta 등의 다른 OIDC 제공자 — 에 위임하는 OpenID Connect(OIDC) 인증 방법과, Boundary 자체의 password 인증 방법을 지원해요. 인증 방법 안에는 **계정(account)**이 만들어져 사용자와 연관될 수 있어요. 사용자와 연관되면 주체는 자기 인증 방법이 지정한 방법으로 Boundary에서 인증할 수 있어요. password 인증 방법의 계정은 로그인 이름과 비밀번호로 구성돼요. 사용자는 서로 다른 인증 방법의 계정과 연관될 수 있는데, 예를 들어 Azure Active Directory 계정과 Okta 계정을 모두 가질 수 있어요. 이런 경우 사용자는 두 제공자 중 하나로 인증할 수 있어요.

접근 관리(Access management)

Boundary의 접근 관리 방식은 가장 낮은 레벨인 **동작(Action)**에서 시작돼요. 동작은 Boundary 리소스에 대해 수행할 수 있는 능력이에요. Boundary는 Create, Read, Update, Delete, List 같은 일반적인 동작을 지원해요. 그러나 부여(grants)에서 사용할 수 있는 리소스 유형 특화 동작이 훨씬 더 많아요.

접근 관리의 다음 레벨은 **부여(grant)**예요. Boundary의 부여에는 동작(들)과 그 동작을 수행할 수 있는 리소스(들)가 포함돼요. 규칙(rule)처럼 생각할 수 있어요.

예를 들어, 부여는 특정 리소스에 대해 List 동작을 지정할 수 있어요. 부여는 리소스 유형이나 리소스 ID를 지정할 수 있으며, 규칙으로 구현될 수도 있어요.

가장 높은 레벨은 **역할(role)**의 개념을 사용해요. 역할은 0개 이상의 부여 모음이에요. 역할은 주체(사용자와 그룹)에 할당되며, 그들이 수행할 권한이 있는 동작을 관장해요. 역할은 단일 스코프에 속하며 그 수명 주기는 스코프의 존재에 의존해요. 스코프가 삭제되면 역할도 삭제돼요. 아래 다이어그램은 Boundary 내의 서로 다른 IAM 구성 요소 간의 관계를 보여줘요.

워커(Workers)

지금까지 설명한 리소스들은 Boundary의 제어 플레인(control plane)을 구성해요. **워커(worker)**는 데이터 플레인(data plane)을 구성해요. 워커는 사용자와 대상 사이의 **세션(session)**을 프록시하는 서비스를 나타내는 리소스예요. 이를 통해 private 리소스에 접근을 제공하면서, 그 리소스가 실행되는 네트워크를 노출하지 않을 수 있어요. 워커는 멀티홉(multi-hop) 구성을 통해 Vault에 도달하도록 설정할 수도 있고, 세션 녹화를 위한 스토리지 버킷에 접근을 제공할 수도 있어요.

워커는 global 스코프에만 존재해요. controller-led, worker-led, 또는 공유 KMS 사용 중 하나의 방법으로 제어 플레인에 등록해요. 워커에 태그를 할당하고, 그 태그를 대상(target)이나 스토리지 버킷(storage bucket)의 필터에 사용해 어떤 워커가 그 리소스의 트래픽을 처리할지 제어할 수 있어요.

대상 및 호스트 리소스

Boundary는 사용자에게 엔드포인트를 **대상(target)**으로 노출해요. 대상은 네트워크 서비스를 나타내는 리소스이며, 연관된 권한 집합을 가지고 있어요. 사용자가 단일 세션 안에서 Boundary에 연결하고 상호작용할 수 있게 해주죠. 대상은 호스트(host) 소스나 주소, 그리고 자격 증명(credential) 소스에 대한 참조를 포함할 수 있어요. 대상에 접근하는 사용자는 대상의 자격 증명 소스에서 반환된 자격 증명으로, 대상의 주소 또는 호스트 소스 중 하나에 대한 권한 있는 세션을 만들어요.

대상은 네트워크 서비스 표현을 위해 두 가지 서로 구별되고 상호 배타적인 구성 경로를 노출해요.

주소가 있는 대상 (Target with an address)
호스트 소스가 있는 대상 (Target with host sources)

주소가 있는 대상은 대상 리소스에 단일 IP 주소나 DNS 이름이 직접 설정된 대상을 나타내요. 이 메커니즘은 새 Boundary 사용자와, 호스트·호스트 셋·호스트 카탈로그가 제공하는 유연성이 필요 없는 사용자에게 이점을 제공해요. 그룹으로 묶어 접근 제어 관점에서 동등하게 취급하면 안 되는 독립 호스트(stand-alone host)가 있는 경우에 잘 맞아요. 단순함 때문에, 호스트가 많거나 동적 호스트가 있을 때 주소가 있는 대상을 사용하는 것은 권장하지 않아요.

호스트 소스가 있는 대상은 하나 이상의 **호스트 셋(host set)**이 연관된 대상을 나타내요. 대상에 주소를 직접 설정하는 단순함을 포기하는 대신, 네트워크 리소스를 발견하고 분류하기 위한 Hosts·Host Sets·Host Catalogs의 유연성과 확장성을 얻어요. 상당한 수의 리소스가 있는 환경에서 Boundary를 설정할 때는 호스트 소스가 있는 대상을 사용할 것을 권장해요.

리소스 요약

Account(계정) — 구성된 인증 방법에서 발급된 고유한 자격 증명 집합을 나타내는 리소스로, 사용자의 아이덴티티를 확립하는 데 사용할 수 있어요.
Alias(별칭) — 대상 같은 목적지 리소스와 연관된, 전역적으로 고유한 DNS와 유사한 문자열을 나타내는 리소스예요.
Authentication method(인증 방법) — 사용자가 Boundary에 인증하기 위한 메커니즘을 제공하는 리소스예요.
Auth token(인증 토큰) — Boundary가 사용자로부터의 API 요청을 인증하는 데 사용하는 리소스예요. 사용자가 인증 방법을 통해 인증하면 Boundary가 인증 토큰을 만들어요.
Credential(자격 증명) — 하나 이상의 비밀을 포함하는 데이터 구조로, 세션 동안 호스트에서 아이덴티티를 권한 집합이나 능력에 바인딩해요.
Credential library(자격 증명 라이브러리) — 단일 자격 증명 저장소에서 같은 유형과 같은 접근 수준의 자격 증명을 제공하는 리소스예요.
Credential store(자격 증명 저장소) — 서로 다른 유형과 접근 수준의 자격 증명을 검색·저장·잠재적으로 생성할 수 있는 리소스예요. 자격 증명 라이브러리를 포함할 수도 있어요.
Group(그룹) — 접근 제어 목적을 위해 동등하게 취급할 수 있는 사용자 모음을 나타내는 리소스예요.
Host(호스트) — Boundary에서 도달할 수 있는 네트워크 주소를 가진 컴퓨팅 요소를 나타내는 리소스예요.
Host catalog(호스트 카탈로그) — 호스트와 호스트 셋을 포함하는 리소스예요.
Host set(호스트 셋) — 접근 제어 목적을 위해 동등한 것으로 간주되는 호스트 모음을 나타내는 리소스예요.
Managed group(관리 그룹) — 인증 방법을 뒷받침하는 서드파티 서비스가 세운 기준에 따라 계정을 그룹화하는 리소스예요. 역할에서 주체로 사용할 수 있어요.
Role(역할) — 역할에 할당된 모든 주체에게 부여되는 권한 모음을 포함하는 리소스예요.
Session(세션) — 사용자와 호스트 사이의 관련 연결 집합이에요. 세션은 세션 동안 호스트에서 사용자에게 부여된 권한을 정의하는 자격 증명 집합을 포함할 수 있어요.
Session recordings(세션 녹화) — 세션 녹화는 외부 객체 저장소의 파일 디렉터리 구조를 나타내며, 함께 사용자와 대상 사이의 단일 세션 녹화를 이루는 것이에요.
Scope(스코프) — 컨테이너로 모델링된 권한 경계예요.
Storage bucket(스토리지 버킷) — 세션 녹화를 저장하는 데 사용돼요. 스토리지 버킷은 외부 객체 저장소의 버킷을 나타내요.
Storage policy(스토리지 정책) — 스토리지 버킷에 세션 녹화를 저장하는 규칙을 정의해요. 스토리지 정책은 녹화의 보존 기간을 지정할 수 있어요.
Target(대상) — 연관된 권한 집합을 가진 네트워크 서비스를 나타내는 리소스로, 사용자가 세션을 통해 Boundary를 거쳐 연결하고 상호작용할 수 있어요.
User(사용자) — 접근 제어 목적을 위해 개인이나 엔티티를 나타내는 리소스예요.
Worker(워커) — 사용자와 대상 사이의 세션을 프록시하는 서비스를 나타내는 리소스예요.

다음 단계

Boundary를 시작할 때 가장 먼저 살펴봐야 할 리소스는 스코프예요. 다른 모든 리소스는 스코프 안에 포함되거나, 그 자체가 스코프 안에 포함된 다른 리소스 안에 포함돼요. Boundary 내 리소스 구조를 이해하는 데 scopes 절을 참고하세요.