액세스 제어 구성

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

시작하기 전에

  1. API 사용 설정 및 Cloud SDK 설치를 포함하여 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 역할을 사용하여 저장소에 대한 액세스를 제어합니다. 프로젝트 또는 저장소 수준에서 권한을 부여할 수 있습니다.

기본 역할인 Owner, Editor, Viewer를 사용하여 저장소에 대한 액세스 권한을 부여할 수도 있지만, Artifact Registry 역할을 사용하면 최소 권한의 보안 원칙을 적용하여 사용자와 서비스 계정은 필요한 권한만 가지고 있습니다.

Artifact Registry 권한

아래 표에는 Artifact Registry IAM 역할과 여기에 포함된 권한이 나와 있습니다.

역할 설명 권한
roles/artifactregistry.reader Artifact Registry 리더

아티팩트 보기 및 가져오기

  • artifactregistry.repositories.list
  • artifactregistry.repositories.get
  • artifactregistry.repositories.downloadArtifacts
  • artifactregistry.files.list
  • artifactregistry.files.get
  • artifactregistry.packages.list
  • artifactregistry.packages.get
  • artifactregistry.tags.list
  • artifactregistry.tags.get
  • artifactregistry.versions.list
  • artifactregistry.versions.get
roles/artifactregistry.writer Artifact Registry 작성자

아티팩트 읽기 및 쓰기

모든 roles/artifactregistry.reader 권한 및:

  • artifactregistry.repositories.uploadArtifacts
  • artifactregistry.tags.create
  • artifactregistry.tags.update
roles/artifactregistry.repoAdmin Artifact Registry 저장소 관리자

아티팩트 읽기, 쓰기, 삭제

모든 roles/artifactregistry.writer 권한 및:

  • artifactregistry.repositories.deleteArtifacts
  • artifactregistry.packages.delete
  • artifactregistry.tags.delete
  • artifactregistry.versions.delete
roles/artifactregistry.admin Artifact Registry 관리자

저장소 및 아티팩트 만들기 및 관리

모든 roles/artifactregistry.repoAdmin 권한 및:

  • artifactregistry.repositories.create
  • artifactregistry.repositories.update
  • artifactregistry.repositories.delete
  • artifactregistry.repositories.getIamPolicy
  • artifactregistry.repositories.setIamPolicy

다음 표에는 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 역할을 부여하려면 다음 안내를 따르세요.

Console

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

    IAM 페이지 열기

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

  3. 추가를 클릭합니다.

  4. 이메일 주소를 입력합니다. 개인, 서비스 계정 또는 Google 그룹스를 구성원으로 추가할 수 있습니다. 알파 기능을 사용하려면 사용자가 Google 그룹 ar-trusted-testers@googlegroups.com의 구성원이어야 합니다.

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

  6. 저장을 클릭합니다.

gcloud

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

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

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

  • PROJECT는 Artifact Registry가 실행 중인 프로젝트의 ID입니다.
  • MEMBER는 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 문서를 참조하세요.

저장소별 권한 부여

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

Console

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

  1. Cloud Console에서 저장소 페이지를 엽니다.

    저장소 페이지 열기

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

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

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

  5. 이메일 주소를 입력합니다. 개인, 서비스 계정 또는 Google 그룹스를 구성원으로 추가하여 알파 기능에 액세스할 수 있습니다. 사용자는 Google 그룹스 ar-trusted-testers@googlegroups.com의 구성원이어야 합니다.

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

  7. 저장을 클릭합니다.

gcloud

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

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

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

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

  • REPOSITORY는 저장소 ID입니다.
  • MEMBER는 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

Terraform을 사용하여 저장소를 프로비저닝하고 저장소 권한을 부여하는 방법에 대한 자세한 내용은 Terraform과 통합을 참조하세요.

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

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

공개 읽기 전용 액세스에 필요한 저장소를 구성하려면 구성원 allUsers에 Artifact Registry 리더 역할을 부여합니다.

Console

  1. Cloud Console에서 저장소 페이지를 엽니다.

    저장소 페이지 열기

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

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

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

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

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

gcloud

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

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

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

  • REPOSITORY는 저장소 ID입니다.
  • MEMBER는 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'

권한 취소

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

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

Console

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

  1. Cloud Console에서 저장소 페이지를 엽니다.

    저장소 페이지 열기

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

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

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

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

gcloud

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

gcloud projects remove-iam-policy-binding PROJECT --member=MEMBER --role=ROLE
  • PROJECT는 프로젝트 ID입니다.
  • MEMBER는 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은 취소할 역할입니다.

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

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

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

  • REPOSITORY는 저장소 ID입니다.
  • MEMBER는 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

    저장소에 대한 공개 액세스 권한을 취소하려면 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'
 

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

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

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

기본적으로 기본 Compute Engine 기본 서비스 계정에는 동일한 프로젝트 및 read-only 스토리지 액세스 범위의 리소스에 대한 편집자 권한이 있습니다. 서비스 계정 이메일 주소에는 @developer.gserviceaccount.com 서픽스가 포함됩니다.

편집자 권한은 일반적으로 쓰기 액세스 권한을 부여하지만, 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. 이미지를 내보내거나 컨테이너 이외의 형식에 대한 저장소와 상호 작용하거나 클러스터에서 gcloud 명령어를 실행하려면, 클러스터를 만들 때 서비스 계정의 액세스 범위를 설정해야 합니다.

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

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

액세스 범위 설정

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

gcloud container clusters create CLUSTER-NAME --scopes=SCOPE

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

CLUSTER-NAME은 클러스터의 이름입니다. SCOPE는 니즈와 일치하는 범위입니다.

  • Docker 저장소의 경우 다음 옵션 중 하나를 선택합니다.

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

새 클러스터를 만들 때 설정할 수 있는 범위에 대한 자세한 내용은 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 네임스페이스에 생성되는 모든 새 Pod에 imagePullSecret 보안 비밀이 정의됩니다.

커스텀 서비스 계정 구성

커스텀 서비스 계정을 ID로 사용하는 클러스터의 경우, Artifact Registry를 실행 중인 Google Cloud 프로젝트에서 서비스 계정에 필요한 권한을 부여해야 합니다.

다음 단계

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