GCP 동적 호스트 카탈로그
GCP 동적 호스트 카탈로그
Boundary는 동적 호스트 카탈로그를 사용해 GCP Compute Engine VM 인스턴스를 자동으로 발견하고 호스트로 추가해요. 여러분이 정의한 필터로 어떤 인스턴스가 특정 호스트 셋으로 동기화될지 제어할 수 있어요.
동적 호스트 카탈로그는 필터를 사용해 만드는 호스트 셋에 어떤 호스트를 추가할지 선택해요. 예를 들어 GCP에서 호스트를 동기화하는 호스트 카탈로그를 만들고, labels.env:prod로 태그된 모든 GCP Compute Engine VM 인스턴스를 선택하는 production이라는 호스트 셋을 만들 수 있어요.
동적 호스트 카탈로그를 설정하려면:
- 지원되는 인증 방법으로 호스트 카탈로그를 GCP 계정에 인증하세요.
- 동기화할 호스트를 선택하는 필터로 호스트 셋을 만드세요.
서비스 계정(service account), 서비스 가장(service impersonation), 또는 GCP Application Default Credentials(ADC)로 GCP에 인증할 수 있어요.
서비스 계정으로 인증하려면 GCP에서 서비스 계정을 만들고 개인 키 파일을 다운로드하세요.
서비스 계정은 다음 역할을 가져야 해요.
roles/compute.viewer— (필수) 프로젝트의 Compute Engine VM 인스턴스를 나열하려면 필요해요.roles/iam.serviceAccountKeyAdmin— (선택)disable_credential_rotation이false로 설정된 경우 서비스 계정 키를 순환시키려면 필요해요.
**서비스 계정 가장(impersonation)**을 사용하면 Boundary가 다른 서비스 계정을 가장하는 서비스 계정으로 GCP에 인증할 수 있어요. 가장은 Boundary가 사용하는 서비스 계정의 권한을 제한하고 싶을 때 유용해요.
서비스 가장으로 인증하려면 두 개의 서비스 계정을 만들어야 해요.
- Base 서비스 계정 — Boundary가 GCP에 인증하는 데 사용하는 서비스 계정이에요. 이 서비스 계정은 다음 역할을 가져야 해요.
roles/iam.serviceAccountTokenCreator— (필수) 대상 서비스 계정을 위한 토큰을 만들려면 필요해요.roles/iam.serviceAccountKeyAdmin— (선택)disable_credential_rotation이false로 설정된 경우 서비스 계정 키를 순환시키려면 필요해요.
- Target 서비스 계정 — 가장할 서비스 계정이에요. 이 서비스 계정은 다음 역할을 가져야 해요.
roles/compute.viewer— (필수) 프로젝트의 Compute Engine VM 인스턴스를 나열하려면 필요해요.
GCP VM 인스턴스에서 Boundary를 실행한다면 ADC(Application Default Credentials)를 사용해 GCP에 인증할 수 있어요. Boundary는 VM 인스턴스와 연관된 서비스 계정을 사용해 GCP에 인증해요.
Note: GCP에서 개인 키를 다운로드했다면 오류를 일으키는 추가
\n문자가 포함되어 있을 수 있어요.jq유틸리티로 추가\n문자를 제거할 수 있어요. 예:
$ jq -r '.private_key' my-gcp-private-key.json
본문
Boundary는 동적 호스트 카탈로그를 사용해 GCP Compute Engine VM 인스턴스를 자동으로 발견하고 호스트로 추가해요. 여러분이 정의한 필터로 어떤 인스턴스가 특정 호스트 셋으로 동기화될지 제어할 수 있어요.
동적 호스트 카탈로그는 필터를 사용해 만드는 호스트 셋에 어떤 호스트를 추가할지 선택해요. 예를 들어 GCP에서 호스트를 동기화하는 호스트 카탈로그를 만들고, labels.env:prod로 태그된 모든 GCP Compute Engine VM 인스턴스를 선택하는 production이라는 호스트 셋을 만들 수 있어요.
동적 호스트 카탈로그를 설정하려면:
- 지원되는 인증 방법으로 호스트 카탈로그를 GCP 계정에 인증하세요.
- 동기화할 호스트를 선택하는 필터로 호스트 셋을 만드세요.
서비스 계정, 서비스 가장, 또는 GCP Application Default Credentials(ADC)로 GCP에 인증할 수 있어요.
서비스 계정으로 인증하려면 GCP에서 서비스 계정을 만들고 개인 키 파일을 다운로드하세요.
서비스 계정은 다음 역할을 가져야 해요.
roles/compute.viewer— (필수) 프로젝트의 Compute Engine VM 인스턴스를 나열하려면 필요해요.roles/iam.serviceAccountKeyAdmin— (선택)disable_credential_rotation이false로 설정된 경우 서비스 계정 키를 순환시키려면 필요해요.
서비스 계정 가장을 사용하면 Boundary가 다른 서비스 계정을 가장하는 서비스 계정으로 GCP에 인증할 수 있어요. 가장은 Boundary가 사용하는 서비스 계정의 권한을 제한하고 싶을 때 유용해요.
서비스 가장으로 인증하려면 두 개의 서비스 계정을 만들어야 해요.
- Base 서비스 계정 — Boundary가 GCP에 인증하는 데 사용하는 서비스 계정이에요. 다음 역할을 가져야 해요.
roles/iam.serviceAccountTokenCreator— (필수) 대상 서비스 계정을 위한 토큰을 만들려면 필요해요.roles/iam.serviceAccountKeyAdmin— (선택)disable_credential_rotation이false로 설정된 경우 서비스 계정 키를 순환시키려면 필요해요.
- Target 서비스 계정 — 가장할 서비스 계정이에요. 다음 역할을 가져야 해요.
roles/compute.viewer— (필수) 프로젝트의 Compute Engine VM 인스턴스를 나열하려면 필요해요.
GCP VM 인스턴스에서 Boundary를 실행한다면 ADC를 사용해 GCP에 인증할 수 있어요. Boundary는 VM 인스턴스와 연관된 서비스 계정을 사용해 GCP에 인증해요.
Note: GCP에서 개인 키를 다운로드했다면 오류를 일으키는 추가
\n문자가 포함되어 있을 수 있어요.jq유틸리티로 추가\n문자를 제거할 수 있어요. 예:
$ jq -r '.private_key' my-gcp-private-key.json
GCP에 연결하기 위한 호스트 카탈로그 생성
Boundary는 다양한 제공자와 통합하기 위해 플러그인을 사용해요. GCP와 통합하기 위해 동적 호스트 카탈로그를 사용하려면, plugin 유형의 호스트 카탈로그를 만들고 plugin-name 값을 gcp로 설정해요.
또한 Boundary가 GCP에 인증하는 데 필요한 특정 필드들을 제공해야 해요. 필요한 필드는 서비스 계정, 서비스 가장, 또는 GCP ADC 중 어느 것으로 인증하느냐에 따라 달라져요.
GCP를 위한 동적 호스트 카탈로그를 만들려면 다음 단계를 완료하세요.
- Boundary에 로그인하세요.
- org를 선택한 다음 호스트 카탈로그를 만들 프로젝트를 선택하세요.
- Host Catalogs를 선택하세요.
- New Host Catalog를 선택하세요.
- 다음 필드를 완료하세요.
- Name — (선택) 식별 목적으로 호스트 카탈로그에 대한 선택적 이름이에요. 이름을 입력하면 고유해야 해요.
- Description — (선택) 식별 목적으로 호스트 카탈로그에 대한 선택적 설명이에요.
- Type — (필수) 동적 호스트 카탈로그를 만들려면 Dynamic을 선택하세요.
- Provider — (필수) GCP 리소스를 위한 동적 호스트 카탈로그를 만들려면 GCP를 선택하세요.
동적 호스트 카탈로그를 만드는 데 필요한 필드는 구성한 인증 유형에 따라 달라져요.
서비스 계정(Service account):
- Project ID — (필수) 호스트 카탈로그에 추가하려는 인스턴스의 프로젝트 ID예요.
- Zone — (필수) 호스트 카탈로그에 추가하려는 인스턴스의 GCP 영역이에요.
- Client Email — 서비스 계정을 식별하는 데 사용되는 고유한 이메일 주소예요. 서비스 계정으로 인증할 때 필요해요.
- Target Service Account ID — 서비스 계정으로 인증을 구성할 때는 이 필드를 건너뛰세요. 서비스 계정 가장으로 인증할 때만 사용돼요.
- Private Key ID — 개인 키의 고유 식별자예요. 서비스 계정으로 인증할 때 필요해요.
- Private Key — OAuth 2.0 액세스 토큰을 얻는 데 사용되는 개인 키예요. 키는 PEM(Privacy-Enhanced Mail) 인코딩이어야 해요. 서비스 계정으로 인증할 때 필요해요. GCP에서 개인 키를 다운로드했다면 추가
\n문자가 포함되어 오류를 일으킬 수 있어요.jq로 추가\n문자를 제거할 수 있어요.
서비스 가장(Service impersonation):
- Project ID — (필수) 호스트 카탈로그에 추가하려는 인스턴스의 프로젝트 ID예요.
- Zone — (필수) 호스트 카탈로그에 추가하려는 인스턴스의 GCP 영역이에요.
- Client Email — base 서비스 계정을 식별하는 데 사용되는 고유한 이메일 주소예요. 서비스 계정 가장으로 인증할 때 필요해요.
- Target Service Account ID — 가장되는 서비스 계정의 고유 식별자예요. 서비스 계정 가장으로 인증할 때 필요해요.
- Private Key ID — base 서비스 계정의 개인 키 고유 식별자예요. 서비스 계정 가장으로 인증할 때 필요해요.
- Private Key — OAuth 2.0 액세스 토큰을 얻는 데 사용되는 개인 키예요. 키는 PEM 인코딩이어야 해요. 서비스 계정 가장으로 인증할 때 필요해요. GCP에서 개인 키를 다운로드했다면 추가
\n문자가 포함되어 오류를 일으킬 수 있어요.jq로 추가\n문자를 제거할 수 있어요.
Application Default Credential(ADC):
- Project ID — (필수) 호스트 카탈로그에 추가하려는 인스턴스의 프로젝트 ID예요.
- Zone — (필수) 호스트 카탈로그에 추가하려는 인스턴스의 GCP 영역이에요.
- Client Email — (선택) base 서비스 계정을 식별하는 데 사용되는 고유한 이메일 주소예요.
- Target Service Account ID — ADC로 인증을 구성할 때는 이 필드를 건너뛰세요. 서비스 계정 가장으로 인증할 때만 사용돼요.
- Private Key ID — (선택) base 서비스 계정의 개인 키 고유 식별자예요.
- Private Key — (선택) OAuth 2.0 액세스 토큰을 얻는 데 사용되는 개인 키예요. 키는 PEM 인코딩이어야 해요. GCP에서 개인 키를 다운로드했다면 추가
\n문자가 포함되어 오류를 일으킬 수 있어요.jq로 추가\n문자를 제거할 수 있어요.
Worker Filter — (선택) 지정된 워커로 요청을 라우팅하는 선택적 필터예요. Disable credential rotation — (선택) 활성화하면 Boundary가 GCP에서 자격 증명을 자동으로 순환시키지 않아요.
- Save를 선택하세요.
동적 호스트 카탈로그를 만드는 데 필요한 필드는 구성한 인증 유형에 따라 달라져요.
CLI에서 서비스 계정 인증을 위한 GCP 동적 호스트 카탈로그를 만들려면:
-
Boundary에 로그인하세요.
-
다음 명령으로 GCP를 위한 동적 호스트 카탈로그를 만드세요:
$ boundary host-catalogs create plugin \ -scope-id $BOUNDARY_PROJECT_ID \ -plugin-name gcp \ -attr disable_credential_rotation=true \ -attr zone=us-central1-a \ -attr project_id=env://GCP_PROJECT_ID \ -attr client_email=env://CLIENT_EMAIL \ -secret private_key_id=env://PRIVATE_KEY_ID \ -secret private_key=file://$PRIVATE_KEY_FILE_PATH
scope-id와 plugin-name 필드는 동적 호스트 카탈로그를 만들 때 필수예요. attr와 secret 플래그 뒤의 필드는 GCP 특화 필드이며 Boundary가 인증하는 데 사용해요.
disable_credential_rotation— (선택)true로 설정하면 Boundary가 자격 증명을 자동으로 순환시키지 않아요.zone— (필수) 호스트 카탈로그에 추가하려는 인스턴스의 GCP 영역이에요.project_id— (필수) 호스트 카탈로그에 추가하려는 인스턴스의 프로젝트 ID예요.client_email— 서비스 계정을 식별하는 데 사용되는 고유한 이메일 주소예요. 서비스 계정으로 인증할 때 필요해요.private_key_id— 개인 키의 고유 식별자예요. 서비스 계정으로 인증할 때 필요해요.private_key— OAuth 2.0 액세스 토큰을 얻는 데 사용되는 개인 키예요. 키는 PEM 인코딩이어야 해요. 서비스 계정으로 인증할 때 필요해요. GCP에서 개인 키를 다운로드했다면 추가\n문자가 포함되어 오류를 일으킬 수 있어요.jq로 추가\n문자를 제거할 수 있어요.
호스트 카탈로그를 만들 때 사용할 수 있는 추가 필드는 host-catalogs create 명령 문서를 참고하세요.
CLI에서 서비스 가장 인증을 위한 GCP 동적 호스트 카탈로그를 만들려면:
-
Boundary에 로그인하세요.
-
다음 명령으로 GCP를 위한 동적 호스트 카탈로그를 만드세요:
$ boundary host-catalogs create plugin \ -scope-id $BOUNDARY_PROJECT_ID \ -plugin-name gcp \ -attr disable_credential_rotation=true \ -attr zone=us-central1-a \ -attr project_id=env://GCP_PROJECT_ID \ -attr client_email=env://BASE_SERVICE_ACCOUNT_EMAIL \ -attr target_service_account_id=env://TARGET_SERVICE_ACCOUNT_EMAIL \ -secret private_key_id=env://BASE_SERVICE_ACCOUNT_PRIVATE_KEY_ID \ -secret private_key=file://$BASE_SERVICE_ACCOUNT_PRIVATE_KEY_FILE_PATH
scope-id와 plugin-name 필드는 동적 호스트 카탈로그를 만들 때 필수예요. attr와 secret 플래그 뒤의 필드는 GCP 특화 필드이며 Boundary가 인증하는 데 필요해요.
disable_credential_rotation— (선택)true로 설정하면 Boundary가 GCP에서 자격 증명을 자동으로 순환시키지 않아요.zone— (필수) 지역 내 배포 영역이에요. 이 카탈로그의 모든 호스트 셋이 이 영역에 대해 구성돼요.project_id— (필수) 서비스 계정과 연관된 프로젝트 ID예요.client_email— base 서비스 계정을 고유하게 식별하는 데 사용되는 이메일 주소예요. 서비스 계정 가장으로 인증할 때 필요해요.target_service_account_id— 가장할 서비스 계정의 이메일 주소예요. 서비스 계정 가장으로 인증할 때 필요해요.private_key_id— 이 호스트 카탈로그와 함께 사용할 base 서비스 계정 개인 키의 ID예요. 서비스 계정 가장으로 인증할 때 필요해요.private_key— 이 호스트 카탈로그와 함께 사용할 base 서비스 계정의 개인 키예요. 서비스 계정 가장으로 인증할 때 필요해요. GCP에서 개인 키를 다운로드했다면 추가\n문자가 포함되어 오류를 일으킬 수 있어요.jq로 추가\n문자를 제거할 수 있어요.
호스트 카탈로그를 만들 때 사용할 수 있는 추가 필드는 host-catalogs create 명령 문서를 참고하세요.
CLI에서 ADC 인증을 위한 GCP 동적 호스트 카탈로그를 만들려면:
-
Boundary에 로그인하세요.
-
다음 명령으로 GCP를 위한 동적 호스트 카탈로그를 만드세요:
$ boundary host-catalogs create plugin \ -scope-id $BOUNDARY_PROJECT_ID \ -plugin-name gcp \ -attr disable_credential_rotation=true \ -attr zone=us-central1-a \ -attr project_id=env://GCP_PROJECT_ID
scope-id와 plugin-name 필드는 동적 호스트 카탈로그를 만들 때 필수예요. attr 플래그 뒤의 필드는 GCP 특화 필드이며 Boundary가 인증하는 데 필요해요.
disable_credential_rotation— (선택)true로 설정하면 Boundary가 GCP에서 자격 증명을 자동으로 순환시키지 않아요.zone— (필수) 지역 내 배포 영역이에요. 이 카탈로그의 모든 호스트 셋이 이 영역에 대해 구성돼요.project_id— (필수) 서비스 계정과 연관된 프로젝트 ID예요.
호스트 카탈로그를 만들 때 사용할 수 있는 추가 필드는 host-catalogs create 명령 문서를 참고하세요.
동적 호스트 카탈로그를 만드는 데 필요한 필드는 구성한 인증 유형에 따라 달라져요.
다음 예시 속성들의 요구 사항을 배우려면 Boundary Terraform provider 문서를 참고하세요.
서비스 계정 인증을 위한 Terraform 정책을 적용하세요:
resource "boundary_host_catalog_plugin" "gcp_host_catalog" {
name = "GCP Catalog"
description = "GCP Host Catalog"
scope_id = boundary_scope.project.id
plugin_name = "gcp"
# recommended to pass in aws secrets using a file() or using environment variables
attributes_json = jsonencode({
"zone" = "us-central1-a ",
"project_id" = "GCP_PROJECT_ID_VALUE",
"client_email" = "GCP_CLIENT_EMAIL_VALUE",
"disable_credential_rotation" = true })
secrets_json = jsonencode({
"private_key_id" = "GCP_PRIVATE_KEY_ID_VALUE",
"private_key" = "GCP_PRIVATE_KEY_VALUE"})
}
scope_id와 plugin_name 필드는 동적 호스트 카탈로그를 만들 때 필수예요.
attributes_json과 secrets_json 뒤의 필드는 GCP 특화 필드이며 Boundary가 인증하는 데 사용해요.
zone— (필수) 호스트 카탈로그에 추가하려는 인스턴스의 GCP 영역이에요.project_id— (필수) 호스트 카탈로그에 추가하려는 인스턴스의 프로젝트 ID예요.client_email— 서비스 계정을 식별하는 데 사용되는 고유한 이메일 주소예요. 서비스 계정으로 인증할 때 필요해요.disable_credential_rotation— (선택)true로 설정하면 Boundary가 자격 증명을 자동으로 순환시키지 않아요.private_key_id— 개인 키의 고유 식별자예요. 서비스 계정으로 인증할 때 필요해요.private_key— OAuth 2.0 액세스 토큰을 얻는 데 사용되는 개인 키예요. 키는 PEM 인코딩이어야 해요. 서비스 계정으로 인증할 때 필요해요. GCP에서 개인 키를 다운로드했다면 추가\n문자가 포함되어 오류를 일으킬 수 있어요.jq로 추가\n문자를 제거할 수 있어요.
호스트 카탈로그를 만들 때 사용할 수 있는 추가 필드는 Boundary Terraform provider 문서의 boundary_host_catalog_plugin 항목을 참고하세요.
서비스 가장 인증을 위한 Terraform 정책을 적용하세요:
resource "boundary_host_catalog_plugin" "gcp_host_catalog" {
name = "GCP Catalog"
description = "GCP Host Catalog"
scope_id = boundary_scope.project.id
plugin_name = "gcp"
# recommended to pass in aws secrets using a file() or using environment variables
attributes_json = jsonencode({
"zone" = "us-central1-a ",
"project_id" = "GCP_PROJECT_ID_VALUE",
"client_email" = "GCP_BASE_SERVICE_ACCOUNT_EMAIL_VALUE",
"target_service_account_id" = "GCP_TARGET_SERVICE_ACCOUNT_EMAIL_VALUE",
"disable_credential_rotation" = true })
secrets_json = jsonencode({
"private_key_id" = "BASE_SERVICE_ACCOUNT_PRIVATE_KEY_ID_VALUE",
"private_key" = "BASE_SERVICE_ACCOUNT_PRIVATE_KEY_VALUE"})
}
scope_id와 plugin_name 필드는 동적 호스트 카탈로그를 만들 때 필수예요.
attributes_json과 secrets_json 뒤의 필드는 GCP 특화 필드이며 Boundary가 인증하는 데 필요해요.
zone— (필수) 지역 내 배포 영역이에요. 이 카탈로그의 모든 호스트 셋이 이 영역에 대해 구성돼요.project_id— (필수) 서비스 계정과 연관된 프로젝트 ID예요.client_email— base 서비스 계정을 고유하게 식별하는 데 사용되는 이메일 주소예요. 서비스 계정 가장으로 인증할 때 필요해요.target_service_account_id— 가장할 서비스 계정의 이메일 주소예요. 서비스 계정 가장으로 인증할 때 필요해요.disable_credential_rotation— (선택)true로 설정하면 Boundary가 GCP에서 자격 증명을 자동으로 순환시키지 않아요.private_key_id— 이 호스트 카탈로그와 함께 사용할 base 서비스 계정 개인 키의 ID예요. 서비스 계정 가장으로 인증할 때 필요해요.private_key— 이 호스트 카탈로그와 함께 사용할 base 서비스 계정의 개인 키예요. 서비스 계정 가장으로 인증할 때 필요해요. GCP에서 개인 키를 다운로드했다면 추가\n문자가 포함되어 오류를 일으킬 수 있어요.jq로 추가\n문자를 제거할 수 있어요.
호스트 카탈로그를 만들 때 사용할 수 있는 추가 필드는 Boundary Terraform provider 문서의 boundary_host_catalog_plugin 항목을 참고하세요.
ADC 인증을 위한 Terraform 정책을 적용하세요:
resource "boundary_host_catalog_plugin" "gcp_host_catalog" {
name = "GCP Catalog"
description = "GCP Host Catalog"
scope_id = boundary_scope.project.id
plugin_name = "gcp"
# recommended to pass in aws secrets using a file() or using environment variables
attributes_json = jsonencode({
"zone" = "us-central1-a ",
"project_id" = "GCP_PROJECT_ID_VALUE",
"disable_credential_rotation" = true })
}
scope_id와 plugin_name 필드는 동적 호스트 카탈로그를 만들 때 필수예요.
attributes_json 뒤의 필드는 GCP 특화 필드이며 Boundary가 인증하는 데 필요해요.
zone— (필수) 호스트 카탈로그에 추가하려는 인스턴스의 GCP 영역이에요.project_id— (필수) 호스트 카탈로그에 추가하려는 인스턴스의 프로젝트 ID예요.disable_credential_rotation— (선택)true로 설정하면 Boundary가 GCP에서 자격 증명을 자동으로 순환시키지 않아요.
호스트 카탈로그를 만들 때 사용할 수 있는 추가 필드는 Boundary Terraform provider 문서의 boundary_host_catalog_plugin 항목을 참고하세요.
GCP에 연결하기 위한 호스트 셋 생성
호스트 셋은 Boundary가 어떤 GCP 필터를 사용해 추가되어야 할 발견된 호스트를 식별할지 지정해요.
호스트 셋을 만들려면 다음 단계를 완료하세요.
- Boundary에 로그인하세요.
- org를 선택한 다음 호스트 셋을 만들 프로젝트를 선택하세요.
- Host Catalogs를 선택하세요.
- 호스트 셋을 추가하려는 동적 호스트 카탈로그를 선택하세요.
- Host Sets 탭을 클릭하고 New를 클릭하세요.
- 다음 필드를 완료하세요.
- Name — (선택) 식별 목적의 선택적 이름이에요. 이름을 입력하면 고유해야 해요.
- Description — (선택) 식별 목적으로 호스트 카탈로그에 대한 선택적 설명이에요.
- Filter — (선택)
key=val형식의 문자열 필터 배열이에요. key는status같은 필터 옵션에 해당하며, 값은running일 수 있어요. 전체 예시는labels.env:dev예요. 필터 옵션 목록은 GCP API 문서를 참고하세요. 여러 필터를 적용하면 플러그인은 논리AND연산으로 필터를 결합해요. 명시적 인스턴스 상태 필터가 없으면 기본 상태가status="RUNNING"으로 설정돼요. 기본 상태는 Boundary가 실행 중인 인스턴스만 필터링해 결과 처리 시간을 절약한다는 것을 보장해요. 다음 예시처럼 라벨은 더 유연하고 여러 값에 필터링할 수 있으므로 필터로 사용하는 것을 권장해요:labels.env:dev,labels.env:prod AND labels.app:web
- Save를 클릭하세요.
CLI에서:
-
Boundary에 로그인하세요.
-
다음 명령으로 호스트 셋을 만드세요:
$ boundary host-sets create plugin \ -host-catalog-id $BOUNDARY_HOST_CATALOG_ID \ -attr filters=labels.env:prod \ -attr filters=labels.app:web
host-catalog-id 값은 이 호스트 셋을 만들 호스트 카탈로그를 지정하는 필수 필드예요. 호스트 카탈로그와 마찬가지로 attr 플래그 뒤에 전달되는 필드는 GCP 특화 필드예요. filters 필드는 key=val 형식의 문자열 필터를 포함해요. key는 필터 옵션에 해당해요. 필터 옵션 목록은 GCP API 문서를 참고하세요. 여러 필터를 적용하면 플러그인은 논리 AND 연산으로 필터를 결합해요. 명시적 인스턴스 상태 필터가 없으면 기본 상태가 status="RUNNING"으로 설정돼요. 기본 상태는 Boundary가 실행 중인 인스턴스만 필터링해 결과 처리 시간을 절약한다는 것을 보장해요. 다음 예시처럼 라벨은 더 유연하고 여러 값에 필터링할 수 있으므로 필터로 사용하는 것을 권장해요: -attr filters=labels.env:dev, -attr filters="labels.env:prod AND labels.app:web".
호스트 셋을 만들 때 사용할 수 있는 추가 필드는 host-sets create 명령 문서를 참고하세요.
다음 예시 속성들의 요구 사항을 배우려면 Boundary Terraform provider 문서를 참고하세요.
다음 Terraform 정책을 적용하세요:
resource "boundary_host_set_plugin" "gcp_host_set" {
name = "GCP Host Set"
description = "GCP Host Set"
host_catalog_id = boundary_host_catalog_plugin.gcp_host_catalog.id
attributes_json = jsonencode({
"filters" = ["labels.env:prod", "labels.app:web"] })
}
host_catalog_id 값은 이 호스트 셋을 만들 호스트 카탈로그를 지정하는 필수 필드예요.
호스트 카탈로그와 마찬가지로 attributes_json 플래그 뒤에 전달되는 필드는 GCP 특화 필드예요.
filters 필드는 key=val 형식의 문자열 필터를 포함해요. key는 필터 옵션에 해당해요. 필터 옵션 목록은 GCP API 문서를 참고하세요. 여러 필터를 적용하면 플러그인은 논리 AND 연산으로 필터를 결합해요.
명시적 인스턴스 상태 필터가 없으면 기본 상태가 status="RUNNING"으로 설정돼요. 기본 상태는 Boundary가 실행 중인 인스턴스만 필터링해 결과 처리 시간을 절약한다는 것을 보장해요.
다음 예시처럼 라벨은 더 유연하고 여러 값에 필터링할 수 있으므로 필터로 사용하는 것을 권장해요.
-attr filters=labels.env:dev-attr filters="labels.env:prod AND labels.app:web"
호스트 셋을 만들 때 사용할 수 있는 추가 필드는 Boundary Terraform provider 문서의 boundary_host_set_plugin 항목을 참고하세요.
더 알아보기
호스트 카탈로그(host catalogs)와 호스트 셋(host sets)의 도메인 모델 문서를 참고해 이 Boundary 리소스를 더 잘 이해하세요.
Boundary의 필터 문법과 모범 사례에 대한 자세한 내용은 Filtering and listing resources를 참고하세요.