조직 리소스 간 프로젝트 마이그레이션

이 가이드에서는 조직 리소스 또는 리소스 계층 구조 내 위치 간에 프로젝트를 이동하는 방법을 설명합니다.

프로젝트 리소스는 Google Cloud 조직 리소스의 기본 수준 구성 항목입니다. 프로젝트는 조직 리소스 아래에 생성되며 리소스 계층 구조를 형성하는 폴더 또는 조직 리소스 자체에 배치될 수 있습니다. 무엇보다도 인수, 규제 요구사항, 비즈니스 단위 간 구분으로 인해 조직 리소스 간에 프로젝트를 마이그레이션해야 합니다.

Resource Manager API를 사용하여 프로젝트를 조직 리소스 간에 이동하거나 현재 조직 리소스의 리소스 계층 구조에서 다른 위치로 이동할 수 있습니다. 또한 Resource Manager API를 사용하여 마이그레이션을 롤백하고, 리소스 계층 구조에서 원래 위치로 프로젝트를 되돌릴 수 있습니다.

마이그레이션 계획 만들기

프로젝트 이동 중 가장 중요하게 고려해야 할 것은 마이그레이션이 프로젝트 내에서 실행되는 서비스에 주는 영향입니다. Resource Manager API는 프로젝트 리소스와 그 아래에서 실행되는 모든 서비스를 단일 단위로 처리합니다. 즉, 프로젝트 내에 구성 변경 사항이 적용되지 않습니다.

마이그레이션 시 프로젝트에 직접적인 구성 변경사항이 적용되지는 않지만, 리소스 계층 구조의 변경사항은 프로젝트 및 실행 중인 서비스의 기능에 영향을 미칠 수 있습니다. Identity and Access Management 또는 조직 정책과 같이 상속된 정책은 마이그레이션 중에 프로젝트와 함께 이동하지 않으며 리소스에 직접 연결된 정책 및 서비스 계정만 이동합니다. 그러면 마이그레이션이 완료된 후 의도하지 않은 동작이 발생할 수 있습니다.

프로젝트를 이동하면 대상 조직 리소스의 조직 정책에 따라 조직 정책 위반이 발생할 수도 있습니다.

프로젝트를 이동하기 전에 조직 및 이동할 프로젝트의 준비 상태를 확인하는 마이그레이션 계획을 만드는 것이 좋습니다. 이 마이그레이션 계획에서는 프로젝트가 실행 중인 각 서비스와 이동 또는 프로젝트의 대상에서 리소스 계층 구조의 영향을 받을 수 있는 다른 서비스의 현황을 파악합니다.

인벤토리 개요

Cloud 애셋 인벤토리를 사용하여 Identity and Access Management 정책을 비롯한 사용 중인 리소스의 개요를 만듭니다. 이 개요를 통해 마이그레이션 계획을 간략히 정리할 수 있습니다.

또한 Cloud 애셋 인벤토리를 사용하여 이 데이터를 BigQuery로 전송할 수 있습니다. 이렇게 하면 JSON 형식의 데이터를 해석할 때와 비교해서 더 쉽게 읽을 수 있는 SQL을 사용하여 데이터를 쿼리할 수 있습니다. 이 데이터를 내보내는 방법은 BigQuery로 내보내기를 참조하세요.

정책 확인

프로젝트를 마이그레이션하면 프로젝트가 더 이상 리소스 계층 구조의 현재 위치에서 정책을 상속하지 않으며 대상의 유효한 정책 평가가 적용됩니다. 프로젝트 대상의 유효한 정책이 프로젝트의 소스 위치에 있는 정책과 최대한 일치하도록 하는 것이 좋습니다.

프로젝트에 직접 적용된 정책은 마이그레이션이 완료된 후에도 계속 연결됩니다. 이동이 완료된 시점으로부터 올바른 정책이 적용되었는지 확인하기 위해서는 프로젝트에 정책을 직접 적용하는 것이 좋습니다.

Identity and Access Management 정책과 조직 정책은 리소스 계층 구조를 통해 상속되며, 올바르게 설정되지 않으면 서비스가 작동하지 않도록 차단할 수 있습니다. 리소스 계층 구조의 프로젝트 대상에서 유효한 정책을 검토하여 정책이 거버넌스 목표와 일치하는지 확인합니다.

암호화된 키 관리

프로젝트에 고객 관리 암호화 키 또는 다른 Cloud Key Management Service가 사용 설정되었는지 확인해야 합니다. 암호화 키는 프로젝트에서 소유됩니다. 따라서 해당 프로젝트에 대해 owner 액세스 권한이 있는 사용자가 해당 프로젝트에서 Cloud KMS의 키로 암호화 작업을 수행하고 관리할 수 있습니다.

자세한 내용은 업무분장을 참조하세요.

미리보기 기능

조직, 폴더 또는 프로젝트 리소스에서 미리보기 기능을 사용 설정할 수 있습니다. 이동할 프로젝트에 알파 또는 베타 기능을 사용 설정한 경우 마이그레이션 후에도 이 기능이 계속 작동합니다. 미리보기 기능이 비공개 상태이고 대상 조직 리소스에 대해 허용 목록에 포함되지 않은 경우 이동이 완료된 후 구성을 변경할 수 없습니다.

롤백 계획

마이그레이션한 프로젝트에서 작동하지 않는 항목이 발견된 경우 이를 다시 원래 위치로 이동할 수 있습니다. 이를 수행하려면 필요한 IAM 권한이 있어야 하고 프로젝트 마이그레이션을 반대로 실행할 수 있도록 필요한 조직 정책을 설정해야 합니다.

필요한 권한 목록은 권한 할당을 참조하세요. 프로젝트 마이그레이션을 허용하도록 구성해야 하는 조직 정책에 대해서는 조직 정책 구성을 참조하세요.

전용 가져오기 및 내보내기 폴더

정책 상속은 소스 및 대상 조직 리소스 모두에서 프로젝트를 마이그레이션할 때 의도하지 않은 결과를 가져올 수 있습니다. 내보내기 및 가져오기 프로젝트만 보관할 수 있는 특정 폴더를 만들고 두 조직 리소스의 폴더가 동일한 정책을 상속하도록 하면 이러한 위험을 완화할 수 있습니다. 또한 이동할 프로젝트에 상속되는 권한을 이러한 폴더에 설정하여 프로젝트 마이그레이션 프로세스의 속도를 높일 수 있습니다.

마이그레이션을 계획할 때는 전용 소스 폴더를 먼저 설정하는 것이 좋습니다. 이렇게 하려면 프로젝트를 내보내려는 각 조직 리소스에 대해 폴더를 만듭니다. 그런 후 이러한 폴더에 조직 정책을 설정합니다. 각 폴더에서는 프로젝트를 내보내려는 단일 조직 리소스로 constraints/resourcemanager.allowedExportDestinations 제약조건을 설정합니다.

예를 들어 Export to Marketing Org 및 Export to Sales Org 폴더를 설정하고 각 폴더에 적절한 조직 정책 제약조건을 설정할 수 있습니다.

이와 비슷하게, 프로젝트를 가져오려는 각 조직 리소스마다 하나씩 대상 조직 리소스에 전용 가져오기 폴더를 설정합니다. 이렇게 하려면 프로젝트를 가져오려는 각 조직 리소스에 폴더를 만듭니다. 그런 후 이러한 폴더에 조직 정책을 설정합니다. 각 폴더에서는 프로젝트를 가져오려는 단일 조직 리소스로 constraints/resourcemanager.allowedImportSources 제약조건을 설정합니다.

예를 들어 Import from Marketing Org 및 Import from App Development Org 폴더를 설정하고 각 폴더에 적절한 조직 정책 제약조건을 설정할 수 있습니다.

각 가져오기 및 내보내기 폴더에서 프로젝트를 이동할 사용자에게 roles/resourcemanager.projectMover 역할을 할당합니다. 이 역할은 이 폴더 내에 포함된 모든 프로젝트에서 상속하므로 사용자가 해당 폴더로 이동한 모든 프로젝트에서 이동 작업을 수행할 수 있습니다.

프로젝트 마이그레이션을 완료한 후 이러한 전용 폴더를 삭제해야 합니다.

조직 정책 설정에 대한 자세한 내용은 조직 정책 구성을 참조하세요.

권한 할당하기

조직 리소스 간에 프로젝트를 이동하려면 다음 권한이 필요합니다.

원하는 권한을 얻으려면 관리자에게 리소스 계층 구조의 적절한 수준에서 제안된 역할을 부여해 달라고 요청하세요.

프로젝트 이동 권한

프로젝트를 이동하려면 프로젝트, 상위 리소스, 대상 리소스에 대해 다음 역할이 필요합니다.

이동할 프로젝트의 프로젝트 IAM 관리자(roles/resourcemanager.projectIamAdmin)
프로젝트의 상위 리소스의 프로젝트 이동자(roles/resourcemanager.projectMover)
대상 리소스가 폴더인 경우: 대상 리소스의 프로젝트 이동자(roles/resourcemanager.projectMover)
대상 리소스가 조직인 경우: 대상 리소스의 프로젝트 생성자(roles/resourcemanager.projectCreator)

이러한 역할은 다음과 같은 필수 권한을 부여합니다.

필수 권한

이동하려는 프로젝트에 대한 resourcemanager.projects.getIamPolicy
이동하려는 프로젝트에 대한 resourcemanager.projects.update
프로젝트의 상위 리소스에 대한 resourcemanager.projects.move
대상 리소스가 폴더인 경우: 대상 리소스의 resourcemanager.projects.move
대상 리소스가 조직인 경우: 대상 리소스의 resourcemanager.projects.create

커스텀 역할 또는 사전 정의된 다른 역할을 사용하여 이 권한을 얻을 수도 있습니다.

조직 정책 권한

소스 및 대상 조직 리소스에서 조직 정책을 설정하는 사용자는 조직 정책을 만들고 관리할 수 있는 권한을 부여하는 roles/orgpolicy.policyAdmin 역할이 있어야 합니다.

결제 계정 권한

여러 조직 리소스에서 Cloud Billing 계정을 사용할 수 있습니다. 조직 리소스 간에 프로젝트를 이동해도 결제에는 영향을 미치지 않으며 이전 결제 계정에 계속 청구됩니다. 그러나 조직 리소스 이동 시에는 새로운 결제 계정으로 이동해야 한다는 요구 사항이 포함되기도 합니다.

프로젝트의 결제 계정을 변경하는 데 필요한 권한을 얻으려면 관리자에게 다음 IAM 역할을 요청하세요.

대상 결제 계정의 결제 계정 사용자(roles/billing.user)
프로젝트의 프로젝트 결제 관리자(roles/billing.projectManager)

역할 부여에 대한 자세한 내용은 액세스 관리를 참조하세요.

이러한 사전 정의된 역할에는 프로젝트의 결제 계정을 변경하는 데 필요한 권한이 포함되어 있습니다. 필요한 정확한 권한을 보려면 필수 권한 섹션을 확장하세요.

필수 권한

프로젝트의 결제 계정을 변경하려면 다음 권한이 필요합니다.

대상 결제 계정에 대한 billing.resourceAssociations.create
프로젝트에 대한 resourcemanager.projects.createBillingAssignment
프로젝트에 대한 resourcemanager.projects.deleteBillingAssignment

커스텀 역할이나 다른 사전 정의된 역할을 사용하여 이 권한을 부여받을 수도 있습니다.

조직 정책 구성

프로젝트 리소스를 새 조직 리소스로 이동하려면 프로젝트를 이동할 수 있는 조직 리소스를 정의하는 조직 정책을 먼저 적용해야 합니다. 또한 프로젝트를 가져올 수 있는 조직 리소스를 정의하는 조직 정책을 대상에 설정해야 합니다.

이동할 프로젝트에 대한 상위 리소스에서 constraints/resourcemanager.allowedExportDestinations 제약조건을 포함하는 조직 정책을 설정합니다. 그러면 대상 목적지가 프로젝트를 마이그레이션할 수 있는 유효한 위치로 정의됩니다.

대상 조직에서 constraints/resourcemanager.allowedImportSources 제약조건이 포함된 조직 정책을 설정합니다. 그러면 해당 소스가 프로젝트를 마이그레이션할 수 있는 유효한 위치로 정의됩니다.

예를 들어 ID가 12345678901인 조직 리소스에 my-test-project 프로젝트가 있고, 이를 보조 비즈니스 단위의 새 조직 리소스(ID 45678901234)로 이동한다고 가정해 보겠습니다.

organizations/12345678901에 조직 정책을 설정하고, constraints/resourcemanager.allowedExportDestinations 제약조건을 적용하고, under:organizations/45678901234를 allowed_value로 설정합니다.

그런 다음 organizations/45678901234에 조직 정책을 설정하고, constraints/resourcemanager.allowedImportSources 제약조건을 적용하고, under:organizations/12345678901을 allowed_value로 설정합니다.

이러한 조직 정책이 시행되면 권한 할당에 언급된 권한이 있을 경우 organizations/12345678901에서 organizations/45678901234로 my-test-project를 이동할 수 있게 됩니다.

프로젝트의 결제 계정 변경

결제 계정을 변경하려면 다음 안내를 따르세요.

Google Cloud 콘솔의 결제 페이지로 이동합니다.
결제 페이지로 이동
변경할 결제 계정의 이름을 클릭합니다.
이 결제 계정에 연결된 프로젝트에서 이동할 프로젝트의 이름을 찾고 오른쪽에 있는 메뉴 버튼을 클릭합니다.
결제 변경을 클릭하고 새 결제 계정을 선택합니다.
계정 설정을 클릭합니다.

이미 발생했지만 거래 내역에 아직 보고되지 않은 요금은 이전의 결제 계정으로 청구됩니다. 여기에는 프로젝트 이동 시점보다 최대 2일 전 요금이 포함될 수 있습니다.

조직 리소스 간 결제 계정 이동

결제 계정은 조직 리소스 간에 이동할 수 있지만 반드시 필요한 단계는 아닙니다. 대부분의 기존 조직 리소스에는 대신 사용해야 하는 결제 계정이 이미 있습니다. 기존 결제 계정을 이전해야 하는 경우 다음을 수행하세요.

소스 및 대상 조직 리소스에 대한 roles/billing.admin 역할과 대상 조직 리소스에 대한 roles/billing.creator 역할을 가져옵니다.
Google Cloud 콘솔의 결제 페이지로 이동합니다.
결제 페이지로 이동
이동할 결제 계정의 이름을 클릭합니다.
계정 관리 페이지 상단에서 조직 변경을 클릭합니다.
대상 조직 리소스를 선택하고 확인을 클릭합니다.

이제 결제 계정이 지정된 조직 리소스와 연결됩니다.

마이그레이션 수행

적절한 IAM 권한이 있고 필요한 조직 정책이 시행되는 경우 Resource Manager API를 사용하여 프로젝트 리소스를 이동할 수 있습니다.

gcloud

프로젝트를 다른 조직 리소스로 마이그레이션하려면 다음 명령어를 실행합니다.

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

또한 다음 명령어를 사용하여 폴더를 대상 리소스로 지정할 수도 있습니다.

gcloud beta projects move PROJECT_ID \
    --folder FOLDER_ID

각 항목의 의미는 다음과 같습니다.

PROJECT_ID는 마이그레이션하려는 프로젝트의 ID 또는 번호입니다.
ORGANIZATION_ID는 프로젝트를 이동하려는 조직 리소스의 ID입니다. 조직 리소스 또는 폴더 중 하나의 대상만 지정할 수 있습니다.
FOLDER_ID는 프로젝트를 이동하려는 폴더의 ID입니다. 폴더 또는 조직 리소스 중 하나의 대상만 지정할 수 있습니다.

API

v1 Resource Manager API를 사용하여 해당 parent 필드를 대상 리소스의 ID로 설정하여 프로젝트를 이동할 수 있습니다.

프로젝트를 마이그레이션하려면 다음 안내를 따르세요.

projects.get() 메서드를 사용하여 project 객체를 가져옵니다.
parent 필드를 조직 리소스의 ID 또는 이동할 폴더의 ID로 설정합니다.
projects.update() 메서드를 사용하여 project 객체를 업데이트합니다.

다음은 위 단계를 보여주는 코드 스니펫입니다.

    project = crm.projects().get(projectId=flags.projectId).execute()
    project['parent'] = {
        'type': 'organization',
        'id': flags.organizationId
    }

    project = crm.projects().update(
    projectId=flags.projectId, body=project).execute()

마이그레이션 롤백

실수로 프로젝트를 이동한 경우 이전 소스를 새 대상으로, 이전 대상을 새 소스로 지정하고 이동을 다시 수행하여 작업을 롤백할 수 있습니다. 필요한 IAM 권한이 있고 이를 완전히 새로운 마이그레이션처럼 허용하는 조직 정책이 시행 중이어야 합니다.

특수 사례 처리

조직 리소스가 없는 프로젝트 마이그레이션

조직 리소스와 연결되지 않은 프로젝트를 조직 리소스로 마이그레이션할 수 있습니다. 하지만 이 프로세스를 사용해서 이를 다시 조직 없음으로 변경할 수는 없습니다. 조직 리소스와 연관된 프로젝트가 있고 이를 다시 조직 없음으로 되돌리려면 해당 지원 담당자에게 연락하여 도움을 요청하세요.

조직 리소스와 연관되지 않은 프로젝트를 마이그레이션하는 프로세스는 조직 리소스 간에 프로젝트를 마이그레이션하는 프로세스와 비슷하지만, 마이그레이션 계획에 포함된 모든 단계가 필요하지 않습니다. 프로젝트를 조직 리소스로 마이그레이션하려면 다음 단계를 따라야 합니다.

상속할 정책의 이 프로젝트에 미칠 영향을 확인합니다.
필요에 따라 대상 조직 리소스에 전용 가져오기 폴더를 만듭니다.
권한 할당에 설명된 대로 프로젝트 및 대상 상위 항목의 Identity and Access Management 권한을 할당합니다.
결제 계정을 변경해야 하는지 확인합니다.

그런 다음 마이그레이션을 수행할 수 있습니다.

콘솔

프로젝트를 조직 리소스로 마이그레이션하는 방법은 다음과 같습니다.

Google Cloud 콘솔에서 IAM 및 관리자 > 설정 페이지를 엽니다.
설정 페이지 열기
페이지 상단의 프로젝트 선택기를 선택합니다.
조직 선택기에서 조직 없음을 선택합니다. 연결된 조직 리소스가 없으면 조직 선택기가 나타나지 않으며 이 단계를 건너뛸 수 있습니다.
마이그레이션할 프로젝트를 선택합니다.
페이지 상단에서 이전을 클릭합니다.
조직 드롭다운 목록에서 프로젝트를 마이그레이션할 대상 조직 리소스를 선택합니다.

gcloud

프로젝트를 조직 리소스로 마이그레이션하려면 다음 명령어를 실행합니다.

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

각 항목의 의미는 다음과 같습니다.

PROJECT_ID는 조직 리소스로 이동할 프로젝트의 ID입니다.
ORGANIZATION_ID는 프로젝트를 이동할 조직 리소스의 ID입니다.

API

Resource Manager API를 사용하면 parent 필드를 조직 리소스의 ID로 설정하여 프로젝트를 조직 리소스로 이동할 수 있습니다.

프로젝트를 조직 리소스로 마이그레이션하는 방법은 다음과 같습니다.

projects.get() 메서드를 사용하여 project 객체를 가져옵니다.
parent 필드를 조직 리소스의 ID로 설정합니다.
projects.update() 메서드를 사용하여 project 객체를 업데이트합니다.

parent 필드는 설정 후 변경할 수 없습니다.

다음은 위 단계를 보여주는 코드 스니펫입니다.

    project = crm.projects().get(projectId=flags.projectId).execute()
    project['parent'] = {
        'type': 'organization',
        'id': flags.organizationId
    }

공유 VPC

공유 VPC 프로젝트는 다음 특정 조건에 따라 마이그레이션될 수 있습니다. 먼저 소스 조직에서 roles/orgpolicy.policyAdmin 역할이 있는 사용자가 내보낼 프로젝트의 상위 항목에서 constraints/resourcemanager.allowEnabledServicesForExport 제약조건을 포함하는 조직 정책을 설정해야 합니다. 이 제약조건에는 SHARED_VPC가 allowed_value로 나열됩니다.

공유 VPC 호스트 프로젝트를 먼저 마이그레이션하고, 해당 서비스 프로젝트를 모두 마이그레이션해야 합니다. 소스 및 대상 위치에서 조직 간에 일치하는 방화벽 규칙을 선택하여, 잠재적인 문제를 최소화하고, 마이그레이션 중 프로젝트 및 네트워크의 모든 다운타임을 방지하는 것이 좋습니다. 다른 항목을 마이그레이션하는 동안 소스 조직에 일부 서비스 프로젝트를 무기한 남겨둘 경우 네트워크의 정상 상태가 보장되지 않습니다.

호스트 프로젝트를 이동할 경우 이를 소스 조직으로 다시 이동할 수 있지만 서비스 프로젝트 이동을 시작한 후에는 호스트 프로젝트를 다시 이동할 수 있기 전에 이를 모두 이동해야 합니다.

커스텀 Identity and Access Management 역할

커스텀 Identity and Access Management를 조직 수준에서 만들어 리소스에 대한 액세스 권한을 세부적으로 제어할 수 있지만, 이는 생성된 조직 리소스에서만 유효합니다. 사용자의 IAM 정책 binding이 포함된 프로젝트를 조직 수준의 커스텀 IAM 역할로 이동하려고 하면 해당 역할이 대상 조직 리소스에 존재하지 않는다는 실패한 전제조건 오류와 함께 이동이 실패하게 됩니다.

조직 리소스 수준의 커스텀 IAM 역할을 모두 나열하려면 다음 Google Cloud CLI 명령어를 실행하세요.

gcloud iam roles list --organization ORGANIZATION_ID

ORGANIZATION_ID는 역할을 나열하려는 조직 리소스 ID입니다. 조직 리소스 ID를 찾는 방법은 조직 리소스 만들기 및 관리를 참조하세요.

조직 리소스의 커스텀 Identity and Access Management 역할에 대한 정보를 가져오려면 다음 Google Cloud CLI 명령어를 실행합니다.

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

각 항목의 의미는 다음과 같습니다.

ORGANIZATION_ID는 역할의 상위 조직 리소스의 ID입니다.
ROLE_ID는 설명하려는 역할의 이름입니다.

실패한 전제조건 오류를 해결하려면 프로젝트에서 상속받는 각 조직 수준의 커스텀 역할에 해당하는 프로젝트 수준의 커스텀 역할을 만들어야 합니다. 그런 다음 조직 수준의 커스텀 역할을 참조하는 IAM 역할 바인딩을 삭제합니다.

프로젝트가 마이그레이션된 후 대상 조직 리소스에서 조직 수준의 커스텀 역할을 사용하도록 IAM 정책을 업데이트할 수 있습니다.

커스텀 역할에 대한 자세한 내용은 커스텀 역할 만들기 및 관리를 참조하세요.

버킷 잠금

Cloud Storage 버킷 잠금을 사용하면 버킷의 객체를 보존해야 하는 기간을 제어하는 데이터 보존 정책을 Cloud Storage 버킷에 구성할 수 있습니다. 프로젝트가 실수로 삭제되지 않도록 선취권을 사용하여 버킷 잠금이 보호됩니다.

보존 정책 및 선취권은 마이그레이션 중에 프로젝트와 함께 보관되지만 버킷 잠금이 적용된 프로젝트를 이동하는 경우 실수로 인한 이동을 방지해야 합니다.

VPC 서비스 제어 보안 경계

VPC 서비스 제어를 사용하면 Google Cloud 서비스 주위에 프로젝트 기반 보안 경계를 설정하여 데이터 무단 반출 위험을 완화할 수 있습니다. VPC 서비스 제어 보안 경계로 보호되는 프로젝트는 마이그레이션할 수 없습니다.

보안 경계에서 프로젝트를 삭제하려면 서비스 경계 관리를 참조하세요. VPC 서비스 제어 경계의 프로젝트는 경계가 생성되거나 업데이트된 후 최대 하루 동안 조직 리소스 간에 이동하지 못하도록 차단할 수 없습니다. 서비스 경계에서 프로젝트가 삭제된 후 이동 가능해지는 데 몇 시간이 걸릴 수 있습니다.

Dedicated Interconnect

Dedicated Interconnect 객체가 있는 프로젝트 및 이러한 Dedicated Interconnect 객체에 대한 VLAN 연결이 있는 프로젝트를 함께 마이그레이션하는 것이 좋습니다. Dedicated Interconnect 객체 또는 이러한 객체에 대한 VLAN 연결이 있는 프로젝트는 마이그레이션될 수 있고 조직 리소스 간에 작동하지만 분할된 조직 리소스 내에서는 새 VLAN 연결을 만들 수 없습니다.

Dedicated Interconnect 객체가 연결되거나 Dedicated Interconnect 객체에 대한 VLAN 연결이 있는 조직 리소스의 프로젝트에 대한 구성 변경사항은 다른 쪽에 전파되지 않을 수 있으므로 이러한 조직 리소스 간에 프로젝트 분할을 가급적 오래 유지하지 않는 것이 좋습니다.

Partner Interconnect

Partner Interconnect로 프로젝트를 마이그레이션할 때는 특별히 고려해야 할 항목이 없습니다.

프로젝트 간 서비스 계정

프로젝트 간 서비스 계정이 연결된 프로젝트를 이동하는 경우 서비스 계정이 대상 조직 리소스에서 계속 작동합니다. 해당 프로젝트의 도메인을 제한하는 조직 정책이 있더라도 프로젝트가 연결된 서비스 계정으로 계속 작동합니다.

소스 조직 리소스의 다른 프로젝트에 연결된 프로젝트 간 서비스 계정을 소유하는 프로젝트를 이동하는 경우 서비스 계정이 대상 조직 리소스에서 계속 작동합니다. 그러나 소스 조직 리소스의 도메인으로 제한하는 도메인 제한 조직 정책이 적용되는 리소스에는 서비스 계정을 사용할 수 없습니다.

예를 들어 organizations/12345678901에 project-A가 있다고 가정하겠습니다. 이 프로젝트에는 프로젝트 간 서비스 계정으로 설정된 serviceAccount-1이 연결되어 있습니다. organizations/12345678901의 project-B 및 project-C도 serviceAccount-1을 사용합니다.

organizations/12345678901.의 도메인에만 액세스하도록 허용하는 도메인 제한 제약조건이 포함된 조직 정책을 project-C에 적용했습니다.

project-C의 IAM binding에 serviceAccount-1을 추가한 후 project-A를 organizations/45678901234로 이동하면 서비스 계정이 작동합니다.

project-A를 organizations/45678901234로 이동한 후 project-C의 IAM binding에 serviceAccount-1을 추가하려고 하면 binding이 도메인 제한 제약조건을 위반하므로 실패합니다.

지원 기록

진행 중인 지원 기록이 있는 프로젝트를 이동하는 경우 Google 지원 담당자에게 연락하여 마이그레이션이 진행되었음을 알려야 합니다. Google에 진행 중인 지원 기록이 있는 프로젝트는 Google 지원팀에서 새 조직 리소스를 가리키도록 사례 메타데이터를 업데이트할 때까지 해당 지원 기록을 볼 수 없습니다.

OAuth 동의 화면

프로젝트가 내부 OAuth 동의 화면을 사용하도록 구성되었고 이를 다른 조직 리소스로 마이그레이션할 경우 대상 조직 리소스의 구성원만 요청을 승인할 수 있습니다. 이 동작이 수행되려면 최대 24시간까지 걸릴 수 있습니다. 그 때까지는 소스 조직 리소스의 구성원이 요청을 승인할 수 있습니다.

아래 단계에서는 마이그레이션 중 소스 조직 리소스의 구성원의 액세스 권한이 손실되지 않도록 하는 방법을 설명합니다. OAuth 동의 화면 구성을 변경할 필요가 없도록 대상 조직 리소스에서 조직 리소스 구성원에 대해 새 사용자를 만들 수 있습니다.

소스 조직 리소스에서 구성원의 액세스 권한 손실을 방지하려면 다음 안내를 따르세요.

OAuth 동의 화면을 내부 대신 외부로 업데이트합니다.
내부로 표시되었고 민감한 정보를 사용하는 앱은 앱 확인을 신청할 필요가 없습니다. 앱에 민감한 정보가 사용되는 경우, 동의 화면이 외부로 업데이트될 때 승인 화면 전 소스 조직 리소스의 사용자에게 확인되지 않은 앱 화면이 표시됩니다. 이를 방지하기 위해서는 민감한 또는 제한된 범위의 사용을 위해 앱 확인을 신청합니다.

OS 로그인

소스 프로젝트에 OS 로그인이 사용 설정된 경우 주 구성원에게 소스 프로젝트에 액세스할 수 있는 roles/compute.osLoginExternalUser IAM 역할을 할당하여 이들이 대상 조직 리소스에서 액세스 권한을 잃지 않도록 합니다.

리소스에 서비스 계정 연결

대부분의 Google Cloud 서비스의 경우 사용자에게 서비스 계정을 리소스에 연결하기 위해 서비스 계정에 대해 iam.serviceAccounts.actAs 권한이 필요합니다. 하지만 이전에는 사용자에게 서비스 계정을 가장할 수 있는 권한이 없더라도 온보딩을 쉽게 하기 위해 사용자가 특정 서비스를 사용하여 서비스 계정을 리소스에 연결할 수 있었습니다. 자세한 내용은 여기를 참조하세요.

고객의 소스 조직 리소스에 레거시 동작(일반 역할 권한 부여 없이 서비스 계정 연결 가능)이 있고 대상 조직 리소스에는 없는 경우 이러한 서비스 계정을 리소스에 연결하는 roles/iam.serviceAccountUser를 사용자에게 부여합니다. 서비스 계정 가장에 대한 자세한 내용은 서비스 계정 가장을 참조하세요.

조직 리소스에 기존 동작이 있는지 확인하려면 다음을 수행하세요.

Google Cloud 콘솔에서 조직 정책 페이지로 이동합니다.

조직 정책 페이지로 이동
페이지 상단의 프로젝트 선택기에서 기존 상태를 확인할 조직 리소스를 선택합니다.
조직 정책 목록 위에 있는 필터 상자에 constraints/appengine.enforceServiceAccountActAsCheck를 입력합니다.
appengine.enforceServiceAccountActAsCheck 조직 정책이 목록에 표시되면 조직 리소스에 기존 동작이 있습니다.
다음 각 조직 정책 제약조건에 대해 3단계 및 4단계를 반복합니다.
- appengine.enforceServiceAccountActAsCheck
- dataflow.enforceComputeDefaultServiceAccountCheck
- dataproc.enforceComputeDefaultServiceAccountCheck
- composer.enforceServiceAccountActAsCheck
이러한 조직 정책 제약조건이 표시되면 조직 리소스에 기존 동작이 사용됩니다.

소스 조직 리소스에 기존 동작이 있고 대상 조직에 없으면 위에 설명된 대로 역할을 부여합니다. 소스 및 대상 조직 리소스 모두 기존 동작이 있으면 작업을 수행할 필요가 없지만, 의도치 않은 가장을 방지하도록 정책을 적용하는 것이 좋습니다.

Analytics Hub를 사용하여 프로젝트 마이그레이션

Analytics Hub를 사용하는 프로젝트를 다른 조직 리소스로 마이그레이션하는 경우 오류가 발생할 수 있습니다. 오류를 해결하려면 지원팀에 문의하세요.

백업 및 DR 서비스로 프로젝트 마이그레이션

백업 및 DR 서비스를 사용하는 프로젝트는 다른 조직으로 마이그레이션하면 안 됩니다.