Artifact Registry는 컨테이너 이미지를 관리하는 데 권장되는 서비스입니다. Container Registry가 계속 지원되지만 중요한 보안 수정사항만 제공됩니다. Artifact Registry로 전환하는 방법을 알아보세요.

IAM으로 액세스 제어

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

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

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

시작하기 전에

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

  • 프로젝트 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 Console을 사용하여 Container Registry 이미지를 볼 때는 몇 가지 추가 권한이 필요합니다. Cloud Console 사용에 필요한 일반 권한을 참조하세요.

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

스토리지 관리자 역할은 Container Registry에서 사용하지 않는 버킷을 포함하여 전체 프로젝트의 스토리지 버킷을 만들고 삭제할 수 있습니다. 이 역할이 필요한 계정을 신중하게 고려하세요.

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

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

IAM 권한 부여

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

호스트 이름으로 첫 번째 이미지를 푸시하면 레지스트리 호스트와 해당 스토리지 버킷이 프로젝트에 추가됩니다. 예를 들어 gcr.io/my-project에 대한 첫 번째 푸시는 gcr.io 레지스트리 호스트를 프로젝트 ID my-project가 있는 프로젝트에 추가하고 레지스트리의 스토리지 버킷을 만듭니다. 버킷 이름은 다음 형식 중 하나입니다.

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

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

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

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

Google Cloud Console 또는 gsutil 명령줄 도구를 사용하여 버킷에 권한을 부여할 수 있습니다.

제한 및 제약사항

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

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

권한 부여

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

    Cloud Build에는 동일한 프로젝트 내에서 초기 이미지 푸시를 수행하는 데 필요한 권한이 있습니다. 다른 도구로 이미지를 내보내는 경우 Container Registry에 인증하는 데 사용하는 Google Cloud 계정의 권한을 확인합니다.

    Docker로 초기 이미지를 푸시하는 방법에 대한 자세한 내용은 레지스트리 추가를 참조하세요.

  2. Container Registry가 있는 프로젝트에서 레지스트리 호스트에 사용되는 Cloud Storage 버킷에 대한 적절한 권한을 부여합니다.

    Console

    1. Cloud Console에서 Cloud Storage 페이지로 이동합니다.
    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. 추가를 클릭합니다.

    gsutil

    1. 다음 명령어를 실행하여 프로젝트의 버킷을 나열합니다.

      gsutil 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. 셸 또는 터미널 창에서 다음 명령어를 실행합니다.

      gsutil iam ch TYPE:EMAIL-ADDRESS:ROLE gs://BUCKET_NAME
      

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

      • 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: 이미지 가져오기 및 내보내기
      • BUCKET_NAME은 Cloud Storage 버킷의 이름이며 artifacts.PROJECT-ID.appspot.com 또는 STORAGE-REGION.artifacts.PROJECT-ID.appspot.com 양식입니다.

    예를 들어 이 명령어는 my-example-bucket 버킷에서 이미지를 내보내고 가져올 수 있는 권한을 서비스 계정 my-account@my-project.iam.gserviceaccount.com에 부여합니다.

    gsutil iam ch \
      serviceAccount:my-account@my-project.iam.gserviceaccount.com:legacyBucketWriter \
      gs://my-example-bucket
    

    gsutil iam ch 명령어는 레지스트리가 호스팅되는 스토리지 버킷의 IAM 권한을 변경합니다. 추가 예시는 gsutil 문서에서 확인할 수 있습니다.

  3. Container Registry에 이미지를 푸시할 Compute Engine VM 또는 GKE 노드에 대한 액세스를 구성하는 경우 추가 구성 단계는 VM 및 클러스터 구성을 참조하세요.

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

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

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

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

Console

  1. 기본 스토리지 버킷이 존재하도록 이미지를 Container Registry에 내보냈는지 확인합니다.

  2. Cloud Console에서 Container Registry 페이지를 엽니다.

    Container Registry 페이지 열기

  3. 왼쪽 패널에서 설정을 클릭합니다.

  4. 공개 액세스설정 페이지에서 공개 상태를 공개 또는 비공개로 전환합니다. 이 설정은 기본 스토리지 버킷에 대한 액세스를 제어합니다.

    호스트 공개 상태가 공개이면 해당 호스트 위치에 있는 Google Cloud 프로젝트의 모든 이미지에 공개적으로 액세스할 수 있습니다.

gsutil

  1. 기본 스토리지 버킷이 존재하도록 이미지를 Container Registry에 내보냈는지 확인합니다.

  2. 해당 레지스트리에 대한 Cloud Storage 버킷의 이름을 찾습니다. 이렇게 하려면 버킷을 나열해야 합니다.

    gsutil ls
    

    Container Registry 버킷 URL은 gs://artifacts.PROJECT-ID.appspot.com 또는 gs://STORAGE-REGION.artifacts.PROJECT-ID.appspot.com으로 표시됩니다. 각 항목의 의미는 다음과 같습니다.

    • PROJECT-ID는 Google Cloud Console 프로젝트 ID입니다. 도메인 범위 프로젝트의 경우 도메인 이름이 프로젝트 ID의 일부가 됩니다.
    • STORAGE-REGION은 스토리지 버킷의 위치입니다.
      • us - us.gcr.io 호스트의 레지스트리
      • eu - eu.gcr.io 호스트의 레지스트리
      • asia - asia.gcr.io 호스트의 레지스트리
  3. 다음 명령어를 실행하여 Container Registry의 스토리지 버킷에 공개적으로 액세스할 수 있게 합니다. 이 명령어는 버킷의 모든 이미지를 공개적으로 액세스할 수 있게 합니다.

    gsutil iam ch allUsers:objectViewer gs://BUCKET-NAME
    

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

    • gs://BUCKET-NAME은 Container Registry의 버킷 URL입니다.

Container Registry가 공개적으로 액세스 가능한 경우, 모든 사용자가 이미지를 가져올 수 있습니다. 자세한 안내는 레지스트리에서 이미지 가져오기를 참조하세요.

권한 취소

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

Console

  1. Cloud Console에서 Cloud Storage 페이지를 방문합니다.
  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. 삭제할 주 구성원 옆에 있는 휴지통 아이콘을 클릭합니다.

gsutil

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

gsutil iam ch -d PRINCIPAL gs://BUCKET-NAME

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

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

Google Cloud 서비스와 통합

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

Google Cloud 서비스의 기본 권한

Cloud Build 또는 Google Kubernetes Engine과 같은 Google Cloud 서비스는 기본 또는 Google 관리 서비스 계정을 사용하여 동일한 프로젝트 내의 리소스와 상호작용합니다.

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

  • 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 서비스에는 Compute Engine 기본 서비스 계정이 기본 ID로 있습니다.

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

  • IAM 권한은 리소스에 대한 액세스를 결정합니다.
  • 액세스 범위는 VM 인스턴스에서 gcloud 도구 및 클라이언트 라이브러리를 통해 수행된 요청의 기본 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 옵션으로 액세스 범위를 설정합니다.

  1. VM 인스턴스를 중지합니다. 인스턴스 중지를 참조하세요.

  2. 다음 명령어를 사용하여 액세스 범위를 변경합니다.

    gcloud compute instances set-service-account INSTANCE --scopes=SCOPE
    

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

    • INSTANCE는 VM 인스턴스 이름입니다.
    • SCOPE는 VM 서비스 계정에 구성하려는 범위입니다.
      • 이미지 가져오기: storage-ro
      • 이미지 가져오기 및 내보내기: storage-rw
      • 이미지 가져오기 및 내보내기, gcloud 명령어 실행: cloud-platform
  3. 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를 대신하여 동작하는 Google 관리형 서비스 계정입니다. 2020년 10월 5일 이후에 Container Registry API를 사용 설정한 경우 서비스 계정에는 최소 필수 권한 집합이 있습니다. 이전 서비스 계정에는 편집자 역할이 있었습니다. 계정 및 권한 수정에 대한 자세한 내용은 Container Registry 서비스 계정을 참조하세요.

직접 사용해 보기

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

Container Registry 무료로 사용해 보기