Container Registry는 지원 중단되었으며 종료될 예정입니다. 2024년 5월 15일부터 Artifact Registry는 이전 Container Registry를 사용하지 않고 프로젝트의 gcr.io 도메인 이미지를 호스팅합니다. 2025년 3월 18일 이후에는 Container Registry가 종료됩니다.

Google Cloud에서 컨테이너 관리를 시작하려면 Artifact Registry를 사용하세요. Container Registry를 사용하는 경우 Artifact Registry로 전환하여 Google Cloud에서 컨테이너를 관리하는 방법을 알아보세요.

지원 중단 및 종료에 대한 자세한 내용은 지원 중단 페이지와 출시 노트를 참조하세요.

IAM으로 액세스 제어

이 페이지에서는 Container Registry에 대한 액세스를 제어할 수 있는 권한을 설명합니다.

권한을 구성한 후 이미지를 내보내고 가져오는 데 사용하는 Docker 클라이언트에 대해 인증을 구성할 수 있습니다.

Artifact Analysis을 사용해 취약점이 발견된 이미지 등의 컨테이너 메타데이터를 사용하는 경우 Artifact Analysis 문서에서 메타데이터 보기 또는 관리에 대한 액세스 권한 부여에 대한 정보를 확인하세요.

시작하기 전에

사용자 관리 권한이 있는지 확인합니다. 다음 역할 중 하나에 대해 권한이 있어야 합니다.

프로젝트 IAM 관리자(roles/resourcemanager.projectIamAdmin)
보안 관리자(roles/iam.securityAdmin)

이 역할을 부여하는 대신 동일한 권한이 있는 커스텀 역할 또는 사전 정의된 역할을 사용할 수 있습니다.

권한 및 역할

Container Registry와 상호작용하는 모든 사용자, 서비스 계정, 기타 ID는 Cloud Storage에 대한 적절한 Identity and Access Management(IAM) 권한이 있어야 합니다.

일반적으로 Container Registry에 액세스하는 Google Cloud 서비스는 동일한 Google Cloud 프로젝트의 레지스트리에 대한 기본 권한을 사용해서 구성됩니다. 기본 권한이 요구를 충족하지 않을 경우 적절한 권한을 구성해야 합니다.
다른 ID의 경우에는 필요한 권한을 구성해야 합니다.

Cloud Storage 권한을 사용하여 Container Registry 호스트에 대한 액세스를 제어합니다. 다음 표에서는 Container Registry에 필요한 권한이 포함된 Cloud Storage 역할을 보여줍니다.

Google Cloud 콘솔을 사용하여 Container Registry 이미지를 볼 때는 몇 가지 추가 권한이 필요합니다. Cloud 콘솔을 사용하는 데 필요한 일반 권한을 참조하세요.

필수 액세스 권한	역할	권한 부여 위치
기존 레지스트리에서 이미지 가져오기(읽기 전용)	스토리지 객체 뷰어(roles/storage.objectViewer)	레지스트리 스토리지 버킷에 대한 역할 부여
프로젝트의 기존 레지스트리 호스트에서 이미지를 내보내고(쓰기) 가져오기(읽기)	스토리지 기존 버킷 작성자(roles/storage.legacyBucketWriter)	레지스트리 스토리지 버킷에 대한 역할 부여 이 권한은 버킷 수준에서만 사용할 수 있으며, 이를 프로젝트 수준에서 부여할 수 없습니다.
Google Cloud 프로젝트에 레지스트리 호스트를 추가하고 연관된 스토리지 버킷을 만듭니다.	스토리지 관리자(roles/storage.admin)	프로젝트 수준에서 역할 부여

이미지를 푸시하려면 객체 읽기 및 쓰기 권한과 storage.buckets.get 권한이 필요합니다. 스토리지 기존 버킷 작성자 역할에는 단일 Cloud Storage 역할에 필요한 권한이 포함되어 있지만 스토리지 버킷과 객체에 대한 전체 제어 권한은 부여하지 않습니다.

스토리지 관리자 역할은 스토리지 버킷과 객체를 관리할 수 있는 전체 권한을 부여합니다. 프로젝트 수준의 권한을 부여하면 주 구성원이 Container Registry에서 사용하지 않는 버킷을 포함하여 프로젝트의 모든 스토리지 버킷에 액세스할 수 있습니다. 이 역할이 필요한 주 구성원을 신중하게 고려하세요.

기본적으로 Cloud Build 서비스 계정에는 스토리지 관리자 역할의 권한이 포함됩니다. 따라서 이 서비스 계정은 첫 번째 푸시로 레지스트리를 해당 상위 프로젝트에 추가하고 이미지를 해당 상위 프로젝트의 기존 레지스트리에 푸시할 수 있습니다.
Docker 또는 기타 도구를 사용하여 이미지를 만들고 레지스트리에 푸시하는 경우 더 많이 허용되는 스토리지 관리자 역할이 있는 계정을 사용하여 프로젝트에 레지스트리를 추가한 후 스토리지 기존 버킷 작성자 또는 스토리지 객체 뷰어 역할을 이미지를 내보내거나 가져와야 하는 다른 계정에 설정합니다.

Cloud Storage 역할 및 권한에 대한 자세한 내용은 Cloud Storage 문서를 참조하세요.

IAM 권한 부여

Container Registry는 Cloud Storage 버킷을 컨테이너 이미지의 기본 스토리지로 사용합니다. 버킷에 레지스트리에 대한 권한을 부여하여 이미지에 대한 액세스를 제어할 수 있습니다.

호스트 이름에 처음 이미지 푸시를 수행하면 레지스트리 호스트 및 해당 스토리지 버킷이 프로젝트에 추가됩니다. 예를 들어 gcr.io/my-project에 처음 푸시를 수행하면 프로젝트 ID가 my-project인 프로젝트에 gcr.io 레지스트리 호스트가 추가되고 이 레지스트리에 대해 스토리지 버킷이 생성됩니다. 버킷 이름의 형식은 다음 중 하나입니다.

호스트 gcr.io에 저장된 이미지의 경우 artifacts.PROJECT-ID.appspot.com
다른 레지스트리 호스트에 저장된 이미지의 경우 STORAGE-REGION.artifacts.PROJECT-ID.appspot.com

이 첫 번째 이미지 푸시를 성공적으로 수행하려면 푸시를 수행하는 계정에 스토리지 관리자 역할의 권한이 있어야 합니다.

이미지를 처음으로 레지스트리 호스트로 푸시한 후에는 레지스트리 저장소 버킷에 대한 권한을 부여하여 레지스트리의 이미지에 대한 액세스를 제어합니다.

스토리지 기존 버킷 작성자: 내보내기 및 가져오기
스토리지 객체 뷰어: 가져오기만

Google Cloud 콘솔 또는 Google Cloud CLI를 사용하여 버킷에 대한 권한을 부여할 수 있습니다.

제한 및 제약사항

Container Registry 호스트에 대해서는 스토리지 버킷 수준에서만 권한을 부여할 수 있습니다.

Container Registry는 Cloud Storage 버킷 내의 개별 객체에 설정된 권한은 무시합니다.
레지스트리 내의 저장소에 대해서는 권한을 부여할 수 없습니다. 더 세부적인 액세스 제어가 필요한 경우 Artifact Registry에서 제공되는 저장소 수준 액세스 제어가 더 적합할 수 있습니다.
Container Registry 스토리지 버킷에 동일 버킷 수준 액세스를 사용 설정하면 레지스트리에 액세스하는 모든 사용자와 서비스 계정에 권한을 명시적으로 부여해야 합니다. 이 경우 소유자 및 편집자 역할만으로 필요한 권한이 부여되지 않을 수 있습니다.

권한 부여

레지스트리 호스트가 아직 프로젝트에 없으면 스토리지 관리자 역할의 권한이 있는 계정이 첫 번째 이미지를 레지스트리에 푸시해야 합니다. 이렇게 하면 레지스트리 호스트에 대해 스토리지 버킷이 생성됩니다.

Cloud Build에는 동일한 프로젝트 내에서 처음 이미지 푸시를 수행하기 위해 필요한 권한이 포함되어 있습니다. 다른 도구를 사용해서 이미지를 푸시할 때는 Container Registry 인증을 위해 사용하는 Google Cloud 계정의 권한을 확인합니다.

Docker로 초기 이미지를 내보내는 방법에 대한 자세한 내용은 레지스트리 추가를 참조하세요.
Container Registry가 있는 프로젝트에서 레지스트리 호스트에 사용되는 Cloud Storage 버킷에 대한 적절한 권한을 부여합니다.

참고: 프로젝트 수준에서는 스토리지 기존 버킷 작성자 권한을 부여할 수 없으며 전체 프로젝트에서 스토리지 객체 뷰어 권한을 부여하면 Container Registry에서 사용되지 않는 스토리지 버킷을 포함하여 모든 스토리지 버킷에 대한 액세스 권한이 제공됩니다.
콘솔
1. Google Cloud 콘솔의 Cloud Router 페이지로 이동합니다.
2. 버킷의 링크 artifacts.PROJECT-ID.appspot.com 또는 STORAGE-REGION.artifacts.PROJECT-ID.appspot.com을 클릭합니다.
  
  PROJECT-ID를 Container Registry를 호스팅하는 프로젝트의 Google Cloud 프로젝트 ID로, STORAGE-REGION을 멀티 리전 이미지를 호스팅하는 레지스트리의 asia(eu, us)로 바꿉니다.
3. 권한 탭을 선택합니다.
4. 추가를 클릭합니다.
5. 주 구성원 필드에서 액세스가 필요한 계정의 이메일 주소를 쉼표로 구분해서 입력합니다. 이 이메일 주소는 다음 중 하나일 수 있습니다.
  - Google 계정(예: someone@example.com)
  - Google 그룹(예: my-developer-team@googlegroups.com)
  - IAM 서비스 계정
    
    연관된 서비스 계정의 이메일 주소를 보려면 일반적으로 레지스트리에 액세스하는 Google Cloud 서비스 목록을 참조하세요. 서비스가 Container Registry와 다른 프로젝트에서 실행되는 경우 해당 프로젝트에서 서비스 계정의 이메일 주소를 사용해야 합니다.
6. 역할 선택 드롭다운 메뉴에서 Cloud Storage 카테고리를 선택한 다음 적절한 권한을 선택합니다.
  - 스토리지 객체 뷰어: 이미지만 가져오기
  - 스토리지 기존 버킷 작성자: 내보내기 및 가져오기
7. 추가를 클릭합니다.
참고: 이메일 주소와 도메인이 활성 상태인 Google 계정이나 Google Apps 계정에 연결되어 있어야 합니다.
gcloud
1. 다음 명령어를 실행하여 프로젝트의 버킷을 나열합니다.
  gcloud storage ls
  응답은 다음 예시와 같습니다.
  gs://[BUCKET_NAME1]/ gs://[BUCKET_NAME2]/ gs://[BUCKET_NAME3]/ ...
  반환된 버킷 목록의 레지스트리 호스트에 대한 버킷을 찾습니다. 이미지가 저장된 버킷에는 다음 형식 중 하나로 BUCKET-NAME 이름이 포함됩니다.
  - 호스트 gcr.io에 저장된 이미지의 경우 artifacts.PROJECT-ID.appspot.com
  - 다른 레지스트리 호스트에 저장된 이미지의 경우 STORAGE-REGION.artifacts.PROJECT-ID.appspot.com
  장소
  - PROJECT-ID는 Google Cloud 프로젝트 ID입니다.
  - STORAGE-REGION은 스토리지 버킷의 위치입니다.
    
    us - us.gcr.io 호스트의 레지스트리
    
    eu - eu.gcr.io 호스트의 레지스트리
    
    asia - asia.gcr.io 호스트의 레지스트리
2. 셸 또는 터미널 창에서 다음 명령어를 실행합니다.
  gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \ --member=TYPE:EMAIL-ADDRESS \ --role=ROLE
  장소
  - BUCKET_NAME은 Cloud Storage 버킷의 이름이며 artifacts.PROJECT-ID.appspot.com 또는 STORAGE-REGION.artifacts.PROJECT-ID.appspot.com 양식입니다.
  - TYPE은 다음 중 하나일 수 있습니다.
    
    EMAIL-ADDRESS에 서비스 계정이 지정된 경우 serviceAccount
    
    EMAIL-ADDRESS가 Google 계정인 경우 user
    
    EMAIL-ADDRESS가 Google 그룹인 경우 group
  - EMAIL-ADDRESS는 다음 중 하나일 수 있습니다.
    
    Google 계정(예: someone@example.com)
    
    Google 그룹(예: my-developer-team@googlegroups.com)
    
    IAM 서비스 계정
    
    연관된 서비스 계정의 이메일 주소를 보려면 일반적으로 레지스트리에 액세스하는 Google Cloud 서비스 목록을 참조하세요. 서비스가 Container Registry와 다른 프로젝트에서 실행되는 경우 해당 프로젝트에서 서비스 계정의 이메일 주소를 사용해야 합니다.
  - ROLE은 부여할 Cloud Storage 역할입니다.
    
    objectViewer: 이미지 가져오기
    
    legacyBucketWriter: 이미지 내보내기 및 가져오기
예를 들어 이 명령어는 my-example-bucket 버킷에서 이미지를 내보내고 가져올 수 있는 권한을 서비스 계정 my-account@my-project.iam.gserviceaccount.com에 부여합니다.
```
gcloud storage buckets add-iam-policy-binding gs://my-example-bucket \
  --member=serviceAccount:my-account@my-project.iam.gserviceaccount.com \
  --role=roles/storage.objectUser
```
gcloud storage buckets add-iam-policy-binding 명령어는 레지스트리가 호스팅되는 스토리지 버킷의 IAM 권한을 변경합니다. 추가 예시는 gcloud CLI 문서를 참고하세요.

참고: 이메일 주소와 도메인이 활성 상태인 Google 계정이나 Google Apps 계정에 연결되어 있어야 합니다.
Container Registry로 이미지를 푸시하는 Compute Engine VM 또는 GKE 노드에 대한 액세스를 구성하는 경우 자세한 구성 단계는 VM 및 클러스터 구성을 참조하세요.

이미지에 대한 공개 액세스 구성

호스트 위치의 기본 스토리지 버킷에 공개적으로 액세스할 수 있다면 Container Registry에도 공개적으로 액세스할 수 있습니다. 프로젝트 내에서 각 호스트 위치에 있는 모든 이미지는 공개일 수도 있고 비공개일 수도 있습니다. 프로젝트의 호스트에서 특정 이미지만 공개적으로 제공할 수는 없습니다. 특정 이미지만 공개하고 싶다면 다음 방법을 이용하세요.

공개로 설정할 별도의 호스트 위치에 해당 이미지를 유지하거나
공개적으로 액세스할 수 있는 이미지를 저장할 새 프로젝트를 만듭니다.

컨테이너 이미지를 공개적으로 제공하려면 다음 단계에 따라 기본 스토리지 버킷을 공개적으로 액세스할 수 있도록 설정합니다.

기본 스토리지 버킷이 존재하도록 이미지를 Container Registry에 내보냈는지 확인합니다.
해당 레지스트리에 대한 Cloud Storage 버킷의 이름을 찾습니다. 이렇게 하려면 버킷을 나열해야 합니다.
```
gcloud storage ls
```
Container Registry 버킷 URL은 gs://artifacts.PROJECT-ID.appspot.com 또는 gs://STORAGE-REGION.artifacts.PROJECT-ID.appspot.com으로 표시됩니다. 각 항목의 의미는 다음과 같습니다.
- PROJECT-ID는 Google Cloud 프로젝트 ID입니다. 도메인 범위 프로젝트의 경우 도메인 이름이 프로젝트 ID의 일부가 됩니다.
- STORAGE-REGION은 스토리지 버킷의 위치입니다.
  - us - us.gcr.io 호스트의 레지스트리
  - eu - eu.gcr.io 호스트의 레지스트리
  - asia - asia.gcr.io 호스트의 레지스트리
다음 명령어를 실행하여 Container Registry의 스토리지 버킷에 공개적으로 액세스할 수 있게 합니다. 이 명령어는 버킷의 모든 이미지를 공개적으로 액세스할 수 있게 합니다.
```
gcloud storage buckets add-iam-policy-binding gs://BUCKET-NAME \
    --member=allUsers --role=roles/storage.objectViewer
```
각 항목의 의미는 다음과 같습니다.
- gs://BUCKET-NAME은 Container Registry의 버킷 URL입니다.

이미지에 대한 공개 액세스 삭제

콘솔

기본 스토리지 버킷이 존재하도록 이미지를 Container Registry에 내보냈는지 확인합니다.
Google Cloud 콘솔에서 Container Registry 페이지를 엽니다.

Container Registry 페이지 열기
왼쪽 패널에서 설정을 클릭합니다.
공개 액세스의 설정 페이지에서 공개 상태를 비공개로 전환합니다. 이 설정은 기본 저장소 버킷에 대한 액세스를 제어합니다.

gcloud 스토리지

해당 레지스트리에 대한 Cloud Storage 버킷의 이름을 찾습니다. 이렇게 하려면 버킷을 나열해야 합니다.
```
gcloud storage ls
```
Container Registry 버킷 URL은 gs://artifacts.PROJECT-ID.appspot.com 또는 gs://STORAGE-REGION.artifacts.PROJECT-ID.appspot.com으로 표시됩니다. 각 항목의 의미는 다음과 같습니다.
- PROJECT-ID는 Google Cloud 콘솔 프로젝트 ID입니다. 도메인 범위 프로젝트의 경우 도메인 이름이 프로젝트 ID의 일부가 됩니다.
- STORAGE-REGION은 스토리지 버킷의 위치입니다.
  - us - us.gcr.io 호스트의 레지스트리
  - eu - eu.gcr.io 호스트의 레지스트리
  - asia - asia.gcr.io 호스트의 레지스트리
스토리지 버킷에 대한 공개 액세스를 삭제하려면 셸 또는 터미널 창에서 다음 명령어를 실행합니다.
```
gcloud storage bucket remove-iam-policy-binding gs://BUCKET-NAME \
  --member=allUsers --role=roles/storage.objectViewer
```

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

BUCKET-NAME은 원하는 버킷의 이름입니다.

권한 취소

IAM 권한을 취소하려면 다음 단계를 따르세요.

콘솔

Google Cloud 콘솔에서 Cloud Storage 페이지를 방문합니다.
버킷의 링크 artifacts.PROJECT-ID.appspot.com 또는 STORAGE-REGION.artifacts.PROJECT-ID.appspot.com을 클릭합니다. 여기에서 PROJECT-ID는 Container Registry를 호스팅하는 프로젝트의 Google Cloud 프로젝트 ID이며 STORAGE-REGION은 이미지를 호스팅하는 레지스트리의 멀티 리전(asia, eu 또는 us)입니다.
권한 탭을 선택합니다.
삭제할 주 구성원 옆에 있는 휴지통 아이콘을 클릭합니다.

gcloud

셸 또는 터미널 창에서 다음 명령어를 실행합니다.

gcloud storage bucket remove-iam-policy-binding gs://BUCKET-NAME \
    --member=PRINCIPAL --all

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

BUCKET-NAME은 원하는 버킷의 이름입니다.
PRINCIPAL은 다음 중 하나일 수 있습니다.
- Google 계정의 경우 user:EMAIL-ADDRESS
- IAM 서비스 계정의 경우 serviceAccount:EMAIL-ADDRESS
- Google 그룹의 경우 group:EMAIL-ADDRESS
- 공개 액세스를 취소하는 경우 allUsers

Google Cloud 서비스와 통합

대부분의 Google Cloud 서비스 계정의 경우 레지스트리 액세스를 구성하려면 적절한 IAM 권한을 부여해야 합니다.

Google Cloud 서비스의 기본 권한

Cloud Build 또는 Google Kubernetes Engine과 같은 Google Cloud 서비스는 동일한 프로젝트 내에 있는 리소스와 상호작용하기 위해 기본 서비스 계정 또는 서비스 에이전트를 사용합니다.

다음과 같은 경우에는 직접 권한을 구성하거나 수정해야 합니다.

Google Cloud 서비스가 Container Registry와 다른 프로젝트에 있습니다.
기본 권한이 사용자 요구를 충족하지 않습니다. 예를 들어 기본 Compute Engine 서비스 계정에 동일 프로젝트의 스토리지에 대해 읽기 전용 액세스가 있습니다. VM에서 레지스트리로 이미지를 푸시하려면 VM 서비스 계정에 대해 권한을 수정하거나 스토리지에 쓰기 액세스 권한이 있는 계정으로 레지스트리에 인증해야 합니다.
커스텀 서비스 계정을 사용하여 Container Registry와 상호작용

다음 서비스 계정은 일반적으로 Container Registry에 액세스합니다. 서비스 계정의 이메일 주소에는 서비스가 실행되는 프로젝트의 Google Cloud 프로젝트 ID 또는 프로젝트 번호가 포함되어 있습니다.

서비스	서비스 계정	이메일 주소	권한
App Engine 가변형 환경	App Engine 기본 서비스 계정	`PROJECT-ID`@appspot.gserviceaccount.com	편집자 역할이며 스토리지를 읽고 쓸 수 있습니다.
Compute Engine	Compute Engine 기본 서비스 계정	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com	편집자 역할이며 스토리지에 대한 읽기 전용 액세스 권한으로 제한되었습니다.
Cloud Build	Cloud Build 서비스 계정	`PROJECT-NUMBER`@cloudbuild.gserviceaccount.com	기본 권한에는 스토리지 버킷 만들기 및 스토리지에 대한 읽기 및 쓰기 액세스 권한이 포함되어 있습니다.
Cloud Run	Compute Engine 기본 서비스 계정 버전에 대한 기본 런타임 서비스 계정입니다.	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com	편집자 역할이며 스토리지에 대한 읽기 전용 액세스 권한으로 제한되었습니다.
GKE	Compute Engine 기본 서비스 계정 노드의 기본 서비스 계정입니다.	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com	편집자 역할이며 스토리지에 대한 읽기 전용 액세스 권한으로 제한되었습니다.

이미지를 푸시하도록 VM 및 클러스터 구성

Compute Engine 및 Compute Engine을 사용하는 Google Cloud 서비스에는 기본 ID로 Compute Engine 기본 서비스 계정이 포함됩니다.

IAM 권한과 액세스 범위는 모두 VM이 스토리지를 읽고 쓰는 기능에 영향을 줍니다.

IAM 권한은 리소스에 대한 액세스를 결정합니다.
액세스 범위는 VM 인스턴스에서 gcloud CLI 및 클라이언트 라이브러리를 통해 수행된 요청의 기본 OAuth 범위를 결정합니다. 따라서 액세스 범위는 애플리케이션 기본 사용자 인증 정보로 인증할 때 API 메서드에 대한 액세스를 추가로 제한할 수 있습니다.
- 비공개 이미지를 가져오려면 VM 서비스 계정에 이미지의 스토리지 버킷에 대한 read 권한이 있어야 합니다.
- 비공개 이미지를 푸시하려면 VM 서비스 계정에 이미지의 스토리지 버킷에 대한 read-write, cloud-platform, full-control 액세스 범위가 포함되어야 합니다.

Compute Engine 기본 서비스 계정에는 기본적으로 편집자 역할이 포함됩니다. 이 역할에는 대부분의 Google Cloud 서비스에 대한 리소스 만들기 및 업데이트 권한이 포함되어 있습니다. 하지만 기본 서비스 계정 또는 VM과 연결되는 커스텀 서비스 계정 모두, 스토리지 버킷에 대한 기본 액세스 범위는 읽기 전용입니다. 즉, 기본적으로 VM은 이미지를 푸시할 수 없습니다.

Compute Engine 및 GKE와 같은 환경에만 이미지를 배포하려면 액세스 범위를 수정할 필요가 없습니다. 이러한 환경에서 이미지를 레지스트리에 푸시하는 애플리케이션을 실행하려면 추가 구성을 수행해야 합니다.

다음 설정을 위해서는 IAM 권한 또는 액세스 범위 구성을 변경해야 합니다.

VM 또는 클러스터에서 이미지 내보내기: 이미지를 내보내려면 VM 인스턴스 서비스 계정에 storage-ro 대신 storage-rw 범위가 있어야 합니다.
VM 및 Container Registry가 별도의 프로젝트에 있음: Container Registry에서 사용하는 스토리지 버킷에 액세스 할 수 있는 권한을 IAM이 있는 서비스 계정에 부여해야 합니다.
VM에서 gcloud 명령어 실행: 서비스 계정에 cloud-platform 범위가 있어야 합니다. 이 범위는 이미지를 내보내고 가져오고 gcloud 명령어를 실행할 권한을 부여합니다.

범위 구성 단계는 다음 섹션에 있습니다.

VM의 범위 구성

VM을 만들 때 액세스 범위를 설정하려면 -scopes 옵션을 사용합니다.

gcloud compute instances create INSTANCE --scopes=SCOPE

장소

INSTANCE는 VM 인스턴스 이름입니다.
SCOPE는 VM 서비스 계정에 구성하려는 범위입니다.
- 이미지 가져오기: storage-ro
- 이미지 가져오기 및 내보내기: storage-rw
- 이미지 가져오기 및 내보내기, gcloud 명령어 실행: cloud-platform

기존 VM 인스턴스의 범위를 변경하려면 다음 안내를 따르세요.

--scopes 옵션으로 액세스 범위를 설정합니다.

VM 인스턴스를 중지합니다. 인스턴스 중지를 참조하세요.
다음 명령어를 사용하여 액세스 범위를 변경합니다.
```
gcloud compute instances set-service-account INSTANCE --scopes=SCOPE
```
장소
- INSTANCE는 VM 인스턴스 이름입니다.
- SCOPE는 VM 서비스 계정에 구성하려는 범위입니다.
  - 이미지 가져오기: storage-ro
  - 이미지 가져오기 및 내보내기: storage-rw
  - 이미지 가져오기 및 내보내기, gcloud 명령어 실행: cloud-platform
VM 인스턴스를 다시 시작합니다. 중지된 인스턴스 시작을 참조하세요.

기본 서비스 계정 대신 VM에 커스텀 서비스 계정을 사용하려면 VM을 만들거나 VM 설정을 수정할 때 사용할 서비스 계정과 액세스 범위를 지정하면 됩니다.

Google Kubernetes Engine 클러스터의 범위 구성

기본적으로 새 GKE 클러스터는 Cloud Storage 버킷에 대한 읽기 전용 권한을 갖고 생성됩니다.

Google Kubernetes Engine 클러스터를 만들 때 read-write 스토리지 범위를 설정하려면 --scopes 옵션을 사용합니다. 예를 들어 다음 명령어는 범위가 bigquery, storage-rw, compute-ro인 클러스터를 만듭니다.

gcloud container clusters create example-cluster \
--scopes=bigquery,storage-rw,compute-ro

새 클러스터를 만들 때 설정할 수 있는 범위에 대한 자세한 내용은 gcloud container clusters create 명령어에 대한 문서를 참조하세요.

Container Registry 서비스 계정

Container Registry 서비스 에이전트는 Google Cloud 서비스와 상호작용할 때 Container Registry를 대신하여 작동합니다. 2020년 10월 5일 이후 Container Registry API를 사용 설정한 경우 서비스 에이전트에 필요한 최소 권한 집합이 포함됩니다. 이전의 서비스 에이전트에는 편집자 역할이 포함되었습니다. 서비스 에이전트 및 권한 수정에 관한 자세한 내용은 Container Registry 서비스 계정을 참고하세요.

직접 사용해 보기

Google Cloud를 처음 사용하는 경우 계정을 만들어 실제 시나리오에서 Container Registry의 성능을 평가할 수 있습니다. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

Container Registry 무료로 사용해 보기