개별 경계로 VPC 네트워크 마이그레이션 예시

이 예시에서는 이미 서비스 경계에 있는 기존 호스트 프로젝트의 VPC 네트워크를 별도의 경계로 마이그레이션하는 방법을 보여줍니다.

이 예시에서 호스트 프로젝트는 2개의 VPC 네트워크로 구성됩니다. 2개의 서비스 프로젝트는 Cloud Storage 리소스를 호스팅합니다.

다음 다이어그램은 마이그레이션하기 전 예시 호스트 프로젝트의 경계 구성을 보여줍니다.

마이그레이션하기 전 호스트 프로젝트

이 아키텍처 다이어그램은 다음 구성요소를 보여줍니다.

  • 호스트 프로젝트. 호스트 프로젝트에는 2개의 VPC 네트워크 VPC1 및 VPC2가 포함되어 있습니다.
  • 서비스 프로젝트. 서비스 프로젝트 service-project-1 및 service-project-2에는 Cloud Storage 버킷이 포함되어 있으며 서비스 경계로 보호됩니다.
  • 경계. 서비스 경계 perimeter-1은 전체 호스트 프로젝트 및 서비스 프로젝트를 보호합니다. VPC 네트워크 VPC1의 VM VM1 및 VPC 네트워크 VPC2의 VM VM2는 service-project-1 및 service-project-2의 리소스에 액세스할 수 있습니다.

다음 다이어그램은 마이그레이션 후 호스트 프로젝트의 경계 구성을 보여줍니다.

마이그레이션 후 호스트 프로젝트

이 아키텍처 다이어그램은 다음 구성요소를 보여줍니다.

  • Perimeter-1. 이 경계는 VPC 네트워크 VPC1 및 서비스 프로젝트 service-project-1을 보호합니다. VM VM1은 service-project-1의 Cloud Storage 버킷에는 액세스할 수 있지만 service-project-2의 Cloud Storage 버킷에는 액세스할 수 없습니다.
  • Perimeter-2. 이 경계는 VPC 네트워크 VPC2 및 서비스 프로젝트 service-project-2를 보호합니다. VM VM2는 service-project-2의 Cloud Storage 버킷에는 액세스할 수 있지만 service-project-1의 Cloud Storage 버킷에는 액세스할 수 없습니다.

이 마이그레이션 예시에서는 테스트 실행 모드에서 구성이 변경된 후 테스트 실행 구성을 적용하기 전에 확인됩니다. 이 프로세스를 통해 VPC 네트워크와 리소스가 보호되고 마이그레이션 중에 VPC1에서 service-project-1로, VPC2에서 service-project-2로의 프로덕션 트래픽은 중단되지 않습니다.

마이그레이션 프로세스는 다음과 같은 단계로 구성됩니다.

  • VPC 네트워크 및 경계 세부정보 가져오기
  • 테스트 실행 경계 구성 설정
  • 테스트 실행 설정 확인
  • 테스트 실행 구성 적용

VPC 네트워크 및 경계 세부정보 가져오기

이 예시에서는 마이그레이션을 시작하기 전에 VPC 네트워크 및 경계 세부정보 목록을 가져와야 합니다.

호스트 프로젝트의 VPC 네트워크 나열

다음 명령어는 network-host-project의 VPC 네트워크를 나열합니다.

    gcloud compute networks list --project=network-host-project

이 예시는 다음 출력을 생성합니다.

    NAME  SUBNET_MODE  BGP_ROUTING_MODE  IPV4_RANGE  GATEWAY_IPV4
    vpc1  AUTO         REGIONAL
    vpc2  AUTO         REGIONAL

경계 세부정보 가져오기

다음 명령어는 경계의 세부정보를 가져옵니다.

    gcloud access-context-manager perimeters describe perimeter-1

이 예시는 다음 출력을 생성합니다.

name: accessPolicies/<access policy number>/servicePerimeters/perimeter-1
status:
…
  resources:
  - projects/<network-host-project number>
  - projects/<service-project-1 number>
  - projects/<service-project-2 number>

<access policy number>는 테스트 실행 모드 명령어 예시에 사용됩니다. 다음 명령어를 사용하여 기본 액세스 정책을 설정할 수도 있습니다.

    gcloud alpha config set access_context_manager/policy<access policy number>

테스트 실행 구성 설정

이 예시에서는 테스트 실행 명령어를 사용하여 경계 perimeter-1을 업데이트한 후 network-host-project 및 service-project-2를 삭제하고 VPC1을 추가합니다. 그런 다음 테스트 실행 명령어를 실행하여 새 경계 perimeter-2를 만들고 service-project-2 및 VPC2를 추가합니다.

다른 액세스 정책의 경계에 프로젝트를 추가하려면 먼저 기존 액세스 정책의 경계에서 프로젝트를 삭제해야 합니다. 경계에서 프로젝트를 삭제하는 방법에 대한 자세한 내용은 서비스 경계 업데이트를 참조하세요.

테스트 실행 구성 업데이트

다음 명령어는 경계 perimeter-1을 업데이트하여 network-host-project 및 service-project-2를 삭제하고 VPC1을 추가합니다.

    gcloud access-context-manager perimeters dry-run update perimeter-1
     --remove-resources="projects/<network-host-project number>,projects/<service-project-2 number>"
     --add-resources="//compute.googleapis.com/projects/network-host-project/global/networks/vpc1"
     --policy=<access policy number>

테스트 실행 모드에서 새 경계 만들기

다음 명령어는 경계 perimeter-2를 만들고 service-project-2 및 VPC2를 추가합니다.

    gcloud access-context-manager perimeters dry-run create perimeter-2
    --title=perimeter-2 --type="regular"
    --resources="projects/<service-project-2 number>,//compute.googleapis.com/projects/network-host-project/global/networks/vpc2"
    --restricted-services="storage.googleapis.com"
    --policy=<access policy number>

테스트 실행 구성 확인

이 예시에서는 다음 명령어를 실행하여 VPC1에서 service-project-1까지, VPC2에서 service-project-2까지 테스트 실행 오류가 없는지 확인합니다.

service-project-1의 Cloud Storage 버킷을 나열하려면 VPC1에 있는 VM1에 로그인하고 다음 명령어를 실행합니다.

    gcloud storage ls --project=service-project-1

service-project-2의 Cloud Storage 버킷을 나열하려면 다음 명령어를 실행합니다.

    gcloud storage ls --project=service-project-2

테스트 실행 구성은 프로덕션 트래픽에 영향을 주지 않으므로 명령어가 성공적으로 실행됩니다. 하지만 VM1에서 service-project-2에 액세스하기 위한 network-host-project의 감사 로그에는 다음 테스트 실행 오류가 표시됩니다.

    egressViolations: [
    0: {
    servicePerimeter: "accessPolicies/<access policy number>/servicePerimeters/perimeter-1"
    source: "//compute.googleapis.com/projects/network-host-project/global/networks/VPC1"
    sourceType: "Network"
    targetResource: "projects/<service-project-2 number>"
    }
    ]

마찬가지로 VM2에서 service-project-2로의 Cloud Storage 요청에는 테스트 실행 오류가 없으며 VM2에서 service-project-1로의 요청에는 network-host-project의 감사 로그에 다음 테스트 실행 오류가 있습니다.

    egressViolations: [
    0: {
    servicePerimeter: "accessPolicies/<access policy number>/servicePerimeters/perimeter-2"
    source: "//compute.googleapis.com/projects/network-host-project/global/networks/VPC2"
    sourceType: "Network"
    targetResource: "projects/<service-project-1 number>"
    }
    ]

테스트 실행 구성 적용

하나의 원자적 트랜잭션에서 모든 테스트 실행 구성을 한 번에 적용해야 합니다.

테스트 실행 구성을 적용하려면 다음 명령어를 실행합니다.

    gcloud access-context-manager perimeters dry-run enforce-all --policy=<access policy number>

테스트 실행 구성을 적용한 후 다음 명령어를 실행하여 perimeter-1을 설명합니다.

    gcloud access-context-manager perimeters describe perimeter-1 --policy=<access policy number>

이 예시는 network-host-project 및 service-project-2가 삭제되고 VPC1이 perimeter-1에 추가된 다음 출력을 생성합니다.

    name: accessPolicies/<access policy number>/servicePerimeters/perimeter-1
    status:
    …
    resources:
    - projects/<service-project-1 number>
    - //compute.googleapis.com/projects/<network-host-project>/global/networks/VPC1

다음 명령어를 실행하여 perimeter-2를 설명합니다.

    gcloud access-context-manager perimeters describe perimeter-2 --policy=<access policy number>

이 예시에서는 service-project-2 및 VPC2가 perimeter-2에 추가된 다음 출력을 생성합니다.

    name: accessPolicies/<access policy number>/servicePerimeters/perimeter-2
    status:
    …
    resources:
    - projects/<service-project-2 number>
    - //compute.googleapis.com/projects/<network-host-project>/global/networks/VPC2
    title: perimeter-2