역할 및 권한 구성

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

이 페이지에서는 Artifact Registry 저장소에 권한을 부여하는 방법을 설명합니다.

시작하기 전에

  1. API 사용 설정 및 Google Cloud CLI 설치를 포함하여 Artifact Registry를 사용 설정합니다.
  2. 저장소별 권한을 적용하려면 패키지의 저장소를 만듭니다.

개요

Artifact Registry는 CI/CD 파이프라인을 구현할 수 있도록 Google Cloud 서비스와 완벽하게 통합되어 있으므로 기본 권한으로 설정하는 수고를 최소화할 수 있습니다. 또한 Artifact Registry를 타사 CI/CD 도구와 통합하고 저장소에 액세스하는 데 필요한 권한과 인증을 구성할 수 있습니다.

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

Google Cloud 통합

기본적으로 다음 권한이 Artifact Registry와 동일한 프로젝트의 Google Cloud CI/CD 서비스에 적용됩니다.

모든 서비스가 동일한 Google Cloud 프로젝트에 있고 기본 권한이 니즈를 충족하면 권한을 구성하지 않아도 됩니다.

다음과 같은 경우에는 Artifact Registry 권한을 구성해야 합니다.

  • 이러한 서비스를 사용하여 다른 프로젝트의 Artifact Registry에 액세스해야 합니다. Artifact Registry를 사용하는 프로젝트에서 각 서비스의 서비스 계정에 필요한 역할을 부여합니다.
  • 기본적으로 Artifact Registry에서 이미지 가져오기를 지원하지 않는 GKE 버전을 사용하고 있습니다. 구성 안내는 GKE 섹션을 참조하세요.
  • 기본 서비스 계정에 저장소에 대한 읽기 및 쓰기 액세스 권한이 있어야 합니다. 자세한 내용은 다음 정보를 참조하세요.
  • 기본 서비스 계정 대신 런타임 환경용 사용자 제공 서비스 계정을 사용하고 있습니다. Artifact Registry를 사용하는 프로젝트에서 서비스 계정에 필요한 역할을 부여합니다.

타사 통합

타사 클라이언트의 경우에는 권한과 인증을 모두 구성해야 합니다.

  1. 애플리케이션 대신 작동하도록 서비스 계정을 만들거나 CI/CD 자동화에 사용할 기존 서비스 계정을 선택합니다.
  2. 저장소 액세스 권한을 부여하기 위해 서비스 계정에 적절한 Artifact Registry 역할을 부여합니다.
  3. Artifact Registry로 인증하도록 타사 클라이언트를 구성합니다.

역할 및 권한

권한이 포함된 역할을 부여하여 Identity and Access Management(IAM) 권한을 부여합니다. 프로젝트 또는 저장소 수준에서 권한을 부여할 수 있습니다.

사전 정의된 Artifact Registry 역할

IAM은 특정 Google Cloud 리소스에 대한 액세스 권한을 부여하고 다른 리소스에 승인되지 않은 액세스를 방지하는 사전 정의된 역할을 제공합니다.

Artifact Registry에는 다음과 같은 유형의 사전 정의된 역할을 사용할 수 있습니다.

역할 설명
Artifact Registry 리더
(roles/artifactregistry.reader)
아티팩트 보기 및 가져오기, 저장소 메타데이터 보기를 수행합니다.
Artifact Registry 작성자
(roles/artifactregistry.writer)
아티팩트 읽기 및 쓰기를 수행합니다.
Artifact Registry 저장소 관리자
(roles/artifactregistry.repoAdmin)
아티팩트 읽기, 쓰기, 삭제를 수행합니다. 태그를 만들고 삭제합니다.
Artifact Registry 관리자
(roles/artifactregistry.admin)
저장소 및 아티팩트 만들기 및 관리를 수행합니다.

각 역할의 개별 권한에 대한 전체 목록은 Artifact Registry 역할을 참조하세요. 또한 gcloud iam roles describe 명령어를 사용하여 각 역할의 권한 목록을 볼 수 있습니다.

기본 IAM 역할

기본 IAM 역할은 모든 Google Cloud 리소스에 대한 전역, 프로젝트 수준의 액세스 권한을 사용자에게 부여합니다. 사용자 및 서비스 계정에 필요한 권한만 포함되도록 가능한 모든 경우에 저장소 액세스에 대해 사전 정의된 역할을 사용하세요.

다음 표에는 IAM 이전에 있던 기본 역할과 여기에 포함된 Artifact Registry IAM 역할이 나와 있습니다.

역할 역할 이름 포함된 역할
roles/viewer 뷰어 roles/artifactregistry.reader
roles/editor 편집자 roles/artifactregistry.writer
roles/owner 소유자
  • roles/artifactregistry.repoAdmin
  • roles/artifactregistry.admin

권한 부여

프로젝트의 모든 저장소에 동일한 권한이 적용되는 경우 프로젝트 수준에서 권한을 부여합니다. 일부 계정에 다른 수준의 액세스 권한이 필요하면 저장소 수준에서 역할을 부여합니다.

gcloud 명령어를 사용하여 역할을 부여하는 경우 주 구성원의 단일 역할 바인딩을 지정하거나 정책 파일을 사용하여 여러 바인딩을 정의할 수 있습니다.

다음 참조 정책 템플릿은 이 페이지의 예시에 사용됩니다. 참조 정책 파일 이름은 policy.yaml입니다. 템플릿에는 사용자와 서비스 계정 이름 예시가 포함되어 있습니다. 이러한 예시 사용자와 서비스 계정을 프로젝트에 맞게 바꿉니다.

정책 형식에 대한 자세한 내용은 IAM 정책 문서를 참조하세요.

bindings:

- members:
  - user: user@gmail.com
  role: roles/owner

- members:
  - serviceAccount: repo-readonly@iam.gserviceaccount.com
  - user: user2@gmail.com
  role: roles/artifactregistry.reader

- members:
  - serviceAccount: repo-write@iam.gserviceaccount.com
  role: roles/artifactregistry.writer

- members:
  - serviceAccount: repo-admin@iam.gserviceaccount.com
  role: roles/artifactregistry.repoAdmin

- members:
  - serviceAccount: ar-admin@iam.gserviceaccount.com
  role: roles/artifactregistry.admin

프로젝트 전체 권한 부여

프로젝트의 모든 저장소에 동일한 권한이 적용되는 경우 프로젝트 수준에서 역할을 부여합니다.

프로젝트에 팀 구성원을 추가하고 Artifact Registry 역할을 부여하려면 다음 안내를 따르세요.

콘솔

  1. Google Cloud Console에서 IAM 페이지를 엽니다.

    IAM 페이지 열기

  2. 프로젝트 선택을 클릭하고 Artifact Registry를 실행 중인 프로젝트를 선택하고 열기를 클릭합니다.

  3. 추가를 클릭합니다.

  4. 이메일 주소를 입력합니다. 개인, 서비스 계정 또는 Google 그룹스를 주 구성원으로 추가할 수 있습니다.

  5. 주 구성원의 역할을 선택합니다. 최소 권한의 보안 원칙에 따라 다른 리소스에 대한 무단 액세스를 방지하는 데 필요한 최소 권한을 부여하는 것이 좋습니다.

  6. 저장을 클릭합니다.

gcloud

단일 주 구성원에게 역할을 부여하려면 다음 명령어를 실행합니다.

gcloud projects add-iam-policy-binding PROJECT \
    --member=PRINCPAL \
    --role=ROLE

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

  • PROJECT는 Artifact Registry가 실행 중인 프로젝트의 ID입니다.
  • PRINCIPAL은 binding이 추가되는 주 구성원입니다. user|group|serviceAccount:email 또는 domain:domain 형식을 사용합니다.

    예시: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com 또는 domain:example.domain.com

  • ROLE은 부여할 역할입니다.

자세한 내용은 add-iam-policy-binding 문서를 참조하세요.

정책 파일을 사용하여 역할을 부여하려면 다음 명령어를 실행합니다.

gcloud projects set-iam-policy PROJECT /PATH/TO/policy.yaml

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

  • PROJECT는 Artifact Registry를 실행 중인 프로젝트의 ID 또는 정규화된 ID입니다.
  • /PATH/TO/policy.yaml은 정책 파일의 경로와 파일 이름입니다.

현재 구성된 정책을 가져오려면 다음 명령어를 실행합니다.

gcloud projects get-iam-policy PROJECT

여기서 PROJECT는 프로젝트 ID이거나 프로젝트의 정규화된 식별자입니다.

자세한 내용은 set-iam-policy 문서를 참조하세요.

저장소별 권한 부여

프로젝트의 저장소마다 다른 수준의 액세스 권한이 사용자나 서비스 계정에 있어야 하면 저장소 수준의 권한을 부여합니다.

콘솔

특정 저장소에 대한 액세스 권한을 부여하려면 다음 안내를 따르세요.

  1. Google Cloud 콘솔에서 저장소 페이지를 엽니다.

    저장소 페이지 열기

  2. 적절한 저장소를 선택합니다.

  3. 정보 패널이 표시되지 않으면 메뉴 바에서 정보 패널 표시를 클릭합니다.

  4. 권한 탭에서 주 구성원 추가를 클릭합니다.

  5. 이메일 주소를 입력합니다. 개인, 서비스 계정 또는 Google 그룹스를 주 구성원으로 추가할 수 있습니다.

  6. 주 구성원의 역할을 선택합니다. 주 구성원에게 필요한 최소 권한을 부여하는 것이 좋습니다.

  7. 저장을 클릭합니다.

gcloud

개별 정책 binding의 IAM 세트를 설정하거나 정책 파일을 사용할 수 있습니다.

단일 주 구성원에게 역할을 부여하려면 다음 명령어를 실행합니다.

gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
    --location LOCATION \
    --member=PRINCIPAL \
    --role=ROLE

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

  • REPOSITORY는 저장소 ID입니다.
  • PRINCIPAL은 binding이 추가되는 주 구성원입니다. user|group|serviceAccount:email 또는 domain:domain 형식을 사용합니다.

    예시: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com 또는 domain:example.domain.com

  • ROLE은 부여할 역할입니다.

  • LOCATION은 저장소의 리전 또는 멀티 리전 위치입니다.

예를 들어 --us-central1 위치에서 my-repo 저장소를 사용하여 사용자 write@gmail.comroles/artifactregistry.writer 역할에 대한 IAM 정책 binding을 추가하려면 다음을 실행합니다.

gcloud artifacts repositories add-iam-policy-binding my-repo \
 --location=us-central1 --member=user:write@gmail.com --role=roles/artifactregistry.writer

정책 파일을 사용하여 역할을 부여하려면 다음 명령어를 실행합니다.

gcloud artifacts repositories set-iam-policy REPOSITORY /PATH/TO/policy.yaml --location=LOCATION

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

  • REPOSITORY는 저장소 ID입니다.
  • /PATH/TO/policy.yaml은 정책 파일의 경로와 파일 이름입니다.
  • LOCATION은 저장소의 리전 또는 멀티 리전 위치입니다.

예를 들어 policy.yaml에 정의된 정책으로 --us-central1 위치에 있는 my-repo 저장소의 IAM 정책을 설정하려면 다음을 실행합니다.

gcloud artifacts repositories set-iam-policy my-repo policy.yaml --location=us-central1

Terraform

google_artifact_registry_repository_iam 리소스를 사용하여 IAM 정책을 구성합니다. 다음 예시에서는 리소스 이름이 repo-account인 서비스 계정을 정의하고 리소스 이름이 my-repo인 저장소에 대한 읽기 액세스 권한을 부여합니다.

Google Cloud에서 Terraform을 처음 사용하는 경우 HashiCorp 웹사이트의 시작하기 - Google Cloud 페이지를 참조하세요.

provider "google" {
    project = "PROJECT-ID"
}

resource "google_artifact_registry_repository" "my-repo"     {
  provider = google-beta

  location = "LOCATION"
  repository_id = "REPOSITORY"
  description = "DESCRIPTION"
  format = "FORMAT"
}

resource "google_service_account" "repo-account" {
  provider = google-beta

  account_id   = "ACCOUNT-ID"
  display_name = "Repository Service Account"
}

resource "google_artifact_registry_repository_iam_member" "repo-iam" {
  provider = google-beta

  location = google_artifact_registry_repository.my-repo.location
  repository = google_artifact_registry_repository.my-repo.name
  role   = "roles/artifactregistry.reader"
  member = "serviceAccount:${google_service_account.repo-account.email}"
}

ACCOUNT-ID는 서비스 계정의 ID으로, @ 기호 앞에 있는 서비스 계정 이메일 필드의 일부입니다.

추가 예시는 google_artifact_registry_repository_iam 리소스의 문서를 참조하세요.

저장소에 대한 공개 액세스 구성

인증 없이 인터넷의 모든 사용자가 사용할 수 있게 하는 아티팩트가 있으면 공개 저장소에 아티팩트를 저장합니다.

공개 읽기 전용 액세스에 필요한 저장소를 구성하려면 주 구성원 allUsers에 Artifact Registry 리더 역할을 부여합니다. 또한 단일 사용자가 프로젝트의 전체 할당량을 사용할 수 없도록 사용자 요청 할당량 상한을 설정하는 것이 좋습니다.

콘솔

  1. Google Cloud 콘솔에서 저장소 페이지를 엽니다.

    저장소 페이지 열기

  2. 적절한 저장소를 선택합니다.

  3. 정보 패널이 표시되지 않으면 메뉴 바에서 정보 패널 표시를 클릭합니다.

  4. 권한 탭에서 주 구성원 추가를 클릭합니다.

  5. 새 주 구성원 필드에 allUsers를 입력합니다.

  6. Artifact Registry 리더 역할을 선택합니다.

  7. Artifact Registry API 요청에 사용자별 한도를 설정하여 인증되지 않은 사용자의 오용을 방지합니다. 자세한 내용은 사용량 상한 설정을 참조하세요.

gcloud

  1. 다음 명령어를 실행합니다.

    gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
    --location=LOCATION --member=allUsers --role=ROLE
    

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

    • REPOSITORY는 저장소 ID입니다.
    • PRINCIPAL은 binding이 추가되는 주 구성원입니다. user|group|serviceAccount:email 또는 domain:domain 형식을 사용합니다.

      예시: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com 또는 domain:example.domain.com

    • ROLE은 부여할 역할입니다.

    • LOCATION은 저장소의 리전 또는 멀티 리전 위치입니다.

    예를 들어 --us-central1 위치에 있는 my-repo 저장소를 공개로 구성하려면 다음을 실행합니다.

    gcloud artifacts repositories add-iam-policy-binding my-repo \
     --location=us-central1 --member=allUsers --role=roles/artifactregistry.reader
    
  2. Artifact Registry API 요청에 사용자별 한도를 설정하여 인증되지 않은 사용자의 오용을 방지합니다. 자세한 내용은 사용량 상한 설정을 참조하세요.

권한 취소

저장소에 대한 액세스 권한을 취소하려면 승인된 주 구성원 목록에서 주 구성원을 삭제합니다.

저장소에서 공개 액세스를 삭제하려면 allUsers 주 구성원을 삭제합니다.

콘솔

권한을 취소하려면 다음 안내를 따르세요.

  1. Google Cloud 콘솔에서 저장소 페이지를 엽니다.

    저장소 페이지 열기

  2. 적절한 저장소를 선택합니다.

  3. 정보 패널이 표시되지 않으면 메뉴 바에서 정보 패널 표시를 클릭합니다.

  4. 권한 탭에서 적절한 주 구성원을 확장합니다. 공개 저장소를 비공개로 설정하려면 allUsers 주 구성원을 확장합니다.

  5. 주 구성원 삭제를 클릭하여 액세스 권한을 취소합니다.

gcloud

프로젝트 수준에서 역할을 취소하려면 다음 명령어를 실행합니다.

gcloud projects remove-iam-policy-binding PROJECT \
    --member=PRINCIPAL \
    --role=ROLE
  • PROJECT는 프로젝트 ID입니다.
  • PRINCIPAL는 바인딩을 삭제할 주 구성원입니다. user|group|serviceAccount:email 또는 domain:domain 형식을 사용합니다.

    예시: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com 또는 domain:example.domain.com

  • ROLE은 취소할 역할입니다.

저장소의 역할을 취소하려면 다음 명령어를 실행합니다.

gcloud artifacts repositories remove-iam-policy-binding REPOSITORY
    --member=PRINCIPAL \
    --role=ROLE

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

  • REPOSITORY는 저장소 ID입니다.
  • PRINCIPAL는 바인딩을 삭제할 주 구성원입니다. user|group|serviceAccount:email 또는 domain:domain 형식을 사용합니다.

    예시: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com 또는 domain:example.domain.com

    저장소에 대한 공개 액세스 권한을 취소하려면 allUsers 주 구성원을 지정합니다.

  • ROLE은 취소할 역할입니다.

예를 들어 --us-central1 위치에서 my-repo 저장소를 사용하여 사용자 write@gmail.comroles/artifactregistry.writer 역할에 대한 정책 binding을 삭제하려면 다음을 실행합니다.

gcloud artifacts repositories remove-policy-binding my-repo \
    --location=us-central1 \
    --member=user:write@gmail.com \
    --role=roles/artifactregistry.writer

--us-central1 위치에서 my-repo에 대한 공개 액세스를 취소하려면 다음을 실행합니다.

gcloud artifacts repositories remove-policy-binding my-repo \
    --location=us-central1 \
    --member=allUsers \
    --role=roles/artifactregistry.reader
 

태그를 사용한 조건부 액세스 권한 부여

이 기능은 미리보기 상태입니다.

프로젝트 관리자는 Google Cloud에서 리소스에 대한 태그를 만들고 Resource Manager에서 관리할 수 있습니다. Artifact Registry 저장소에 태그를 연결하면 관리자는 IAM 조건이 있는 태그를 사용하여 저장소에 조건부 액세스 권한을 부여할 수 있습니다.

개별 아티팩트에 태그를 연결할 수 없습니다.

자세한 내용은 다음 문서를 참조하세요.

Google Cloud 서비스와 통합

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

Google Cloud 서비스의 기본 권한

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

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

  • Google Cloud 서비스가 Artifact Registry와 다른 프로젝트에 있습니다.
  • 기본 권한이 사용자 요구를 충족하지 않습니다. 예를 들어 기본 Compute Engine 서비스 계정에 동일 프로젝트의 스토리지에 대해 읽기 전용 액세스가 있습니다. VM에서 Artifact Registry로 이미지를 내보내려면 VM 서비스 계정의 권한을 수정하거나 필요한 권한이 있는 다른 계정을 사용할 수 있습니다.
  • 기본 서비스 계정 대신 Artifact Registry와 상호작용하는 데 사용자 제공 서비스 계정을 사용합니다.

다음 서비스 계정은 일반적으로 Artifact 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 편집자 역할이며 저장소에 대한 읽기 전용 액세스 권한으로 제한되었습니다.

Compute Engine 인스턴스에 대한 액세스 권한 부여

저장소에 액세스하는 VM 인스턴스에는 Artifact Registry 권한과 스토리지 액세스 범위가 구성되어 있어야 합니다.

서비스 계정의 액세스 수준은 서비스 계정에 부여된 IAM 역할에 따라 결정되는 반면, VM 인스턴스의 액세스 범위는 인스턴스의 gcloud CLI 및 클라이언트 라이브러리를 통해 이루어진 요청의 기본 OAuth 범위를 결정합니다. 따라서 액세스 범위는 애플리케이션 기본 사용자 인증 정보로 인증할 때 API 메서드에 대한 액세스를 추가로 제한할 수 있습니다.

Compute Engine은 다음 기본값을 사용합니다.

  • Compute Engine 기본 서비스 계정은 VM 인스턴스의 ID입니다. 서비스 계정 이메일 주소에는 @developer.gserviceaccount.com 서픽스가 포함됩니다.
  • 이 동작을 사용 중지하지 않은 경우 기본 서비스 계정에 IAM 기본 편집자 역할이 포함됩니다.
  • 기본 서비스 계정으로 만드는 인스턴스에는 스토리지에 대한 읽기 전용 액세스를 포함하여 Compute Engine 기본 액세스 범위가 포함됩니다. 편집자 역할이 일반적으로 쓰기 액세스를 부여하지만 read-only 스토리지 액세스 범위는 인스턴스 서비스 계정을 동일 프로젝트에 있는 저장소에서만 아티팩트를 다운로드하도록 제한합니다.

다음과 같은 경우에는 서비스 계정의 액세스 범위를 구성해야 합니다.

  • VM 서비스 계정이 다른 프로젝트의 저장소에 액세스해야 합니다.
  • VM 서비스 계정이 저장소에서 아티팩트 읽기 이외의 작업을 수행해야 합니다. 이는 일반적으로 이미지를 푸시하거나 Artifact Registry gcloud 명령어를 실행해야 하는 VM에 타사 도구를 적용합니다.

권한을 구성하고 액세스 범위를 설정하려면 다음 안내를 따르세요.

  1. VM 인스턴스가 있는 프로젝트에서 Compute Engine 기본 서비스 계정 이름을 가져옵니다. 서비스 계정 이메일 주소에는 @developer.gserviceaccount.com 서픽스가 포함됩니다.

  2. 저장소가 있는 프로젝트에서 서비스 계정이 저장소에 액세스할 수 있도록 권한을 부여합니다.

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

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

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

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

      SCOPE를 적절한 값으로 바꿉니다.

      • Docker의 경우 다음 옵션이 지원됩니다.

        • storage-ro - 이미지를 가져오기 위해 읽기 권한만 부여합니다.
        • storage-rw - 이미지를 내보내거나 가져오기 위해 읽기 및 쓰기 권한을 부여합니다.
        • cloud-platform - Google Cloud 서비스에서 메타데이터를 포함한 데이터를 보고 관리합니다.
      • 다른 형식의 경우 cloud-platform 범위를 사용해야 합니다.

    3. VM 인스턴스를 다시 시작합니다. 중지된 인스턴스 시작을 참조하세요.

Google Kubernetes Engine 클러스터에 대한 액세스 권한 부여

GKE 클러스터 및 노드 풀은 다음 요구사항이 모두 충족되는 경우 추가 구성 없이 컨테이너를 가져올 수 있습니다.

GKE 환경에서 이러한 요구사항을 충족하지 않으면 액세스 권한을 부여하는 안내는 Compute Engine 기본 서비스 계정을 사용하는지 또는 사용자 제공 서비스 계정을 노드의 ID로 사용하는지 여부에 따라 달라집니다.

기본 서비스 계정

다음 구성 요구사항은 Compute Engine 기본 서비스 계정에 적용됩니다.

  1. GKE가 Artifact Registry 외 다른 프로젝트에 있으면 서비스 계정에 필요한 권한을 부여합니다.

  2. 이미지를 내보내거나 컨테이너 이외의 형식에 대한 저장소와 상호 작용하거나 클러스터에서 gcloud 명령어를 실행하려면, 클러스터 또는 노드 풀을 만들 때 서비스 계정의 액세스 범위를 설정해야 합니다.

  3. GKE의 지원 버전을 사용하지 않으면 imagePullSecrets를 구성합니다.

사용자 제공 서비스 계정

사용자 제공 서비스 계정을 클러스터의 ID로 사용하려면 다음을 수행해야 합니다.

  1. Artifact Registry를 실행 중인 Google Cloud 프로젝트에서 서비스 계정에 필요한 권한을 부여합니다.

  2. 기본적으로 사용자 제공 서비스 계정으로 클러스터 또는 노드 풀을 만들면 cloud-platform 액세스 범위가 부여됩니다.

    --scopes 플래그와 함께 gcloud container clusters create 또는 gcloud container node-pools create 명령어를 실행하는 경우 Artifact Registry에 사용하도록 적절한 액세스 범위를 포함해야 합니다.

액세스 범위 설정

액세스 범위는 Compute Engine VM에 승인을 지정하는 기존 방법입니다. Artifact Registry 저장소에서 이미지를 가져오려면 GKE 노드에 스토리지 읽기 전용 액세스 범위 또는 스토리지 읽기 액세스를 포함하는 다른 스토리지 액세스 범위가 있어야 합니다.

클러스터 또는 노드 풀을 만들 때만 액세스 범위를 설정할 수 있습니다. 기존 노드에서는 액세스 범위를 변경할 수 없습니다.

  • Compute Engine 기본 서비스 계정을 사용하는 경우 GKE가 스토리지에 대해 읽기 전용 액세스를 포함하는 Compute Engine 기본 액세스 범위로 노드를 만듭니다.
  • 사용자 제공 서비스 계정을 사용하는 경우 GKE는 대부분의 Google Cloud 서비스에 필요한 범위인 cloud-platform 범위로 노드를 만듭니다.

클러스터를 만들 때 액세스 범위를 지정하려면 다음 명령어를 실행합니다.

gcloud container clusters create NAME --scopes=SCOPES

노드 풀을 만들 때 액세스 범위를 지정하려면 다음 명령어를 실행합니다.

gcloud container node-pools create NAME --scopes=SCOPES

다음 값을 바꿉니다.

  • NAME은 클러스터 또는 노드 풀의 이름입니다.
  • SCOPES는 부여할 액세스 범위의 쉼표로 구분된 목록입니다.

    • Docker 저장소에 액세스하려면 다음 범위 중 하나를 사용합니다.

    • storage-ro - 이미지를 가져오기 위한 읽기 전용 권한을 부여합니다.

    • storage-rw - 이미지를 내보내거나 가져오기 위해 읽기 및 쓰기 권한을 부여합니다.

    • cloud-platform - Google Cloud 서비스에서 메타데이터를 포함한 데이터를 보고 관리합니다.

    • 다른 저장소에 액세스하려면 cloud-platform 범위를 사용해야 합니다.

    전체 범위 목록은 gcloud container clusters create 또는 gcloud container node-pools create 문서를 참조하세요.

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

imagePullSecret 구성

imagePullSecret을 구성하려면 다음 안내를 따르세요.

  1. GKE가 있는 프로젝트에서 Compute Engine 기본 서비스 계정을 찾습니다. 계정 이메일 주소에는 @developer.gserviceaccount.com 서픽스가 포함됩니다.

  2. 서비스 계정의 서비스 계정 키를 다운로드합니다.

  3. 저장소가 있는 프로젝트에서 저장소에 권한을 부여했는지 확인합니다.

  4. 클러스터가 있는 프로젝트에서 서비스 계정 키로 artifact-registry라는 imagePullSecret 보안 비밀을 만듭니다.

    kubectl create secret docker-registry artifact-registry \
    --docker-server=https://LOCATION-docker.pkg.dev \
    --docker-email=SERVICE-ACCOUNT-EMAIL \
    --docker-username=_json_key \
    --docker-password="$(cat KEY-FILE)"
    

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

    • LOCATION은 저장소의 리전 또는 멀티 리전 위치입니다.
    • SERVICE-ACCOUNT-EMAIL은 Compute Engine 서비스 계정의 이메일 주소입니다.
    • KEY-FILE은 서비스 계정 키 파일의 이름입니다. 예를 들면 key.json입니다.
  5. 기본 서비스 계정을 엽니다.

    kubectl edit serviceaccount default --namespace default

    Kubernetes 클러스터의 모든 네임스페이스에는 default라고 부르는 기본 서비스 계정이 있습니다. 이 기본 서비스 계정은 컨테이너 이미지를 가져오는 데 사용됩니다.

  6. 새로 생성된 imagePullSecret 보안 비밀을 기본 서비스 계정에 추가합니다.

    imagePullSecrets:
    - name: artifact-registry
    

    서비스 계정은 다음과 같이 표시됩니다.

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: default
      namespace: default
      ...
    secrets:
    - name: default-token-zd84v
    # The secret you created:
    imagePullSecrets:
    - name: artifact-registry
    

이제 현재 default 네임스페이스에 생성되는 모든 새 포드에 imagePullSecret 보안 비밀이 정의됩니다.

Artifact Registry 서비스 계정

Artifact Registry 서비스 에이전트는 Google Cloud 서비스와 상호작용할 때 Artifact Registry를 대신하여 동작하는 Google 관리형 서비스 계정입니다. 계정 및 권한에 대한 자세한 내용은 Artifact Registry 서비스 계정을 참조하세요.

다음 단계

권한을 설정한 후 아티팩트를 사용하는 작업에 대해 자세히 알아보세요.