Container Registry에서 Artifact Registry로 IAM 역할 매핑

이 문서에서는 Container Registry 역할을 Artifact Registry 역할에 매핑하고 이를 Artifact Registry 저장소에 적용하는 방법을 설명합니다. 자동 마이그레이션 도구를 사용하여 동일한 단계를 완료할 수도 있습니다.

Container Registry와 Artifact Registry는 서로 다른 Identity and Access Management(IAM) 역할을 사용하여 레지스트리에 저장된 컨테이너 이미지에 대한 액세스를 제어합니다.

Container Registry에서 Artifact Registry로 전환하는 데 도움이 되도록 다음과 같은 Google Cloud CLI 명령어를 실행할 수 있습니다.

Container Registry의 이미지를 저장하는 Cloud Storage 스토리지 버킷에 적용되는 허용 정책을 식별함
기존 Container Registry 사용자에게 Artifact Registry 저장소에 대한 액세스 권한을 부여할 수 있도록 유사한 Artifact Registry 역할이 있는 정책을 반환함

이 명령어는 IAM 정책 분석 도구를 사용하여 IAM 허용 정책을 분석합니다.

시작하기 전에

Artifact Registry 저장소를 만듭니다. 전환할 수동 방법을 선택한 경우 Artifact Registry의 gcr.io 저장소로 수동으로 이전하거나 표준 저장소로 수동으로 이전하는 단계를 따르세요.
Enable the Cloud Asset API.
Enable the API

기존 허용 정책을 분석하려는 프로젝트 또는 조직에서 API를 사용 설정해야 합니다.
gcloud CLI를 설치하고 초기화하세요. 기존 설치의 경우 다음 명령어를 사용하여 최신 버전으로 업데이트합니다.
```
gcloud components update
```

필요한 역할

허용 정책을 분석하고 Artifact Registry 저장소에 대한 액세스 권한을 부여하는 데 필요한 권한을 얻으려면 관리자에게 분석하고 싶은 프로젝트, 폴더, 조직에 대해 다음 IAM 역할을 부여해 달라고 요청하세요.

Cloud 애셋 뷰어(roles/cloudasset.viewer)
커스텀 IAM 역할로 정책 분석: 역할 뷰어(roles/iam.roleViewer)
Google Cloud CLI를 사용하여 정책 분석: 서비스 사용량 소비자(roles/serviceusage.serviceUsageConsumer)
Artifact Registry 저장소에 대한 역할 부여: Artifact Registry 관리자

역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.

이러한 사전 정의된 역할에는 허용 정책을 분석하고 Artifact Registry 저장소에 대한 액세스 권한을 부여하는 데 필요한 권한이 포함되어 있습니다. 필요한 정확한 권한을 보려면 필수 권한 섹션을 펼치세요.

필수 권한

허용 정책을 분석하고 Artifact Registry 저장소에 대한 액세스 권한을 부여하려면 다음 권한이 필요합니다.

cloudasset.assets.analyzeIamPolicy
cloudasset.assets.searchAllResources
cloudasset.assets.searchAllIamPolicies
커스텀 IAM 역할을 사용하여 정책 분석: iam.roles.get
Google Cloud CLI를 사용하여 정책 분석: serviceusage.services.use
Artifact Registry 저장소에 역할 부여: artifactregistry.repositories.setIamPolicy

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

매핑 도구 사용

매핑 도구는 지정된 Container Registry 호스트 이름(예: gcr.io)에 대한 허용 정책을 확인합니다.

이 도구는 사전 정의된 Cloud Storage 역할에 있는 권한 집합을 확인하고 이를 Artifact Registry 역할에 매핑합니다. Cloud Storage 권한과 Artifact Registry 역할의 비교는 역할 매핑을 참조하세요.

역할 매핑 도구를 사용하려면 다음 안내를 따르세요.

매핑 도구를 실행합니다.
```
gcloud beta artifacts docker upgrade print-iam-policy HOSTNAME \
    --project=PROJECT_ID > POLICY_FILENAME
```
다음 값을 바꿉니다.
- HOSTNAME은 도구에서 분석할 Container Registry 호스트 이름입니다.
  - gcr.io
  - asia.gcr.io
  - eu.gcr.io
  - us.gcr.io
- PROJECT_ID는 분석 중인 레지스트리 호스트가 있는 Google Cloud 프로젝트의 ID입니다.
- POLICY_FILE은 도구에서 반환할 정책의 YAML 형식 파일 이름입니다.
다음 예시 명령어는 버킷에 직접 적용하거나 상위 조직 ID 101231231231 및 하위 요소에서 상속되는 허용 정책에 대하여 my-project 프로젝트에 있는 gcr.io의 스토리지 버킷을 분석합니다.
```
gcloud beta artifacts docker upgrade print-iam-policy gcr.io \
    --project=my-project > gcr-io-policy.yaml
```
이 명령어는 스토리지 버킷의 기존 허용 정책을 기반으로 Artifact Registry 역할 바인딩이 포함된 YAML 형식의 정책 파일을 반환합니다. 스토리지 버킷의 상위 프로젝트가 조직에 있는 경우 정책 파일에는 폴더나 조직 수준에서 액세스 권한이 부여된 주 구성원이 포함됩니다.

예를 들어 다음 샘플에는 다음에 대한 Artifact Registry 역할 바인딩이 포함되어 있습니다.
- Cloud Build, Compute Engine, Container Registry 서비스 에이전트. 서비스 에이전트는 Google Cloud 서비스를 대신하여 작동합니다.
- 사용자 계정 user@example.com
- 사용자 관리형 서비스 계정 deploy@my-project.iam.gserviceaccount.com
```
bindings:
- members:
  - service-3213213213213@gcp-sa-cloudbuild.iam.gserviceaccount.com
  - user:user@example.com
  role: roles/artifactregistry.repoAdmin
- members:
  - serviceAccount:deploy@my-project.iam.gserviceaccount.com
  - serviceAccount:service-1231231231231@@compute-system.iam.gserviceaccount.com
  - serviceAccount:service-1231231231231@containerregistry.iam.gserviceaccount.com
  role: roles/artifactregistry.reader
```
서비스 계정에서 Artifact Registry 저장소에 액세스할 필요가 없으므로 정책 파일에서 Container Registry 서비스 에이전트 줄을 삭제하세요. 서비스 에이전트 이메일 주소의 서픽스는 containerregistry.iam.gserviceaccount.com입니다.

이전 단계의 정책 예시에서 Container Registry 서비스 에이전트가 있는 줄은 다음과 같습니다.
```
- serviceAccount:service-1231231231231@containerregistry.iam.gserviceaccount.com
```
다른 역할 결합을 검토하여 적절한지 확인하세요.

Artifact Registry에는 일부 주 구성원에 대해 고려할 수 있는 추가 사전 정의된 역할이 있습니다. 예를 들어 Artifact Registry Create-on-push 저장소 관리자는 주 구성원이 Artifact Registry에서 gcr.io 저장소를 만들도록 허용하지만 다른 Artifact Registry 저장소를 만드는 것은 허용하지 않습니다.
정책 파일에서 누락된 주 구성원에 대한 역할 결합을 추가하세요.

반환된 정책 파일에서 다음 주 구성원이 누락될 수 있습니다.
- 커스텀 역할이 있는 주 구성원으로 이러한 커스텀 역할에는 도구에서 역할 매핑을 위해 사용되는 권한 집합이 없습니다.
- 상위 폴더 또는 조직을 볼 권한이 없는 경우 상위 폴더 또는 조직에 대한 액세스 권한이 부여된 주 구성원입니다.
Artifact Registry 저장소에 정책 바인딩을 적용합니다.
```
gcloud artifacts repositories set-iam-policy REPOSITORY FILENAME \
    --project=PROJECT_ID \
    --location=LOCATION
```
다음 값을 바꿉니다.
- REPOSITORY는 저장소 이름입니다.
- POLICY_FILENAME은 저장소에 적용할 정책 파일의 이름입니다.
- PROJECT_ID는 프로젝트 ID입니다.
- LOCATION은 저장소의 리전 또는 멀티 리전 위치입니다.
다음 my-project 프로젝트 예에서는 gcr-io-policy.yaml 파일의 정책을 us 멀티 리전의 gcr.io 저장소에 적용합니다.
```
gcloud artifacts repositories set-iam-policy gcr.io gcr-io-policy.yaml \
    --project=my-project \
    --location=us
```
상위 수준 리소스에 역할 결합을 적용하려면 추가할 결합으로 기존 프로젝트, 폴더 또는 조직 정책을 수정하세요.

역할 매핑

다음 표에서는 기존 Container Registry 사용자가 보유한 Cloud Storage 권한에 따라 사용자에게 부여해야 하는 사전 정의된 Artifact Registry 역할을 보여줍니다.

역할의 필수 권한	Artifact Registry 역할
`storage.objects.get` `storage.objects.list`	Artifact Registry 리더
`storage.buckets.get` `storage.objects.get` `storage.objects.list` `storage.objects.create`	Artifact Registry 작성자
`storage.buckets.get` `storage.objects.get` `storage.objects.list` `storage.objects.create` `storage.objects.delete`	Artifact Registry 저장소 관리자
`storage.buckets.get` `storage.objects.get` `storage.objects.list` `storage.objects.create` `storage.buckets.create`	Artifact Registry 관리자