IAM으로 액세스 제어

이 페이지에서는 Artifact Registry에서 Identity and Access Management(IAM)를 사용한 액세스 제어를 설명합니다.

Artifact Registry의 기본 권한은 CI/CD 파이프라인을 구현할 때 설정 작업을 최소화합니다. 또한 Artifact Registry를 타사 CI/CD 도구와 통합하고 저장소에 액세스하는 데 필요한 권한과 인증을 구성할 수 있습니다.

시작하기 전에

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

개요

IAM 권한 및 역할에 따라 Artifact Registry 저장소에서 데이터를 생성, 보기, 수정 또는 삭제할 수 있는 권한이 결정됩니다.

역할은 권한 모음입니다. 주 구성원에게 직접 권한을 부여할 수 없지만 대신 역할을 부여합니다. 주 구성원에게 역할을 부여하면 해당 역할에 포함된 모든 권한이 부여됩니다. 같은 주 구성원에 여러 역할을 부여할 수도 있습니다.

Google Cloud 기본 권한

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

• Cloud Build 권한에는 아티팩트를 업로드하고 다운로드할 수 있는 권한이 포함되어 있습니다.

• Compute Engine, 지원되는 Google Kubernetes Engine 버전, Cloud Run은 스토리지에 대한 읽기 전용 액세스 권한이 있는 Compute Engine 기본 서비스 계정을 사용합니다.

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

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

• 이러한 서비스를 사용하여 다른 프로젝트의 Artifact Registry에 액세스해야 합니다. Artifact Registry를 사용하는 프로젝트에서 각 서비스의 워크로드 아이덴티티 풀 또는 서비스 계정에 필요한 역할을 부여합니다. Cloud Run에 연결하는 경우 Cloud Run 서비스 에이전트에 필요한 역할을 부여합니다.

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

타사 통합

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

일반적으로 Google Cloud 외부에서 실행되는 애플리케이션이 Google Cloud 리소스에 액세스하려면 서비스 계정 키를 사용합니다. 그러나 서비스 계정 키는 강력한 사용자 인증 정보이며 제대로 관리하지 않을 경우 보안상 위험할 수 있습니다.

워크로드 아이덴티티 제휴를 사용하면 Identity and Access Management를 통해 서비스 계정을 가장하는 기능이 포함된 IAM 역할을 외부 ID에 부여할 수 있습니다. 이 접근 방식을 사용하면 서비스 계정 키와 관련된 유지보수 및 보안 부담이 사라집니다.

워크로드 아이덴티티 제휴 사용:

1. 워크로드 아이덴티티 제휴 풀을 만듭니다.
2. 워크로드 아이덴티티 제휴 공급업체를 만듭니다.
3. 저장소 액세스를 허용하기 위해 워크로드 아이덴티티 풀에 적절한 Artifact Registry 역할을 부여합니다.

4. Artifact Registry로 인증하도록 타사 클라이언트를 구성합니다.

   • 컨테이너 이미지: Docker, Helm
   • 언어 패키지: Java, Node.js, Python, Go
   • OS 패키지: Debian, RPM
   • 기타: Kubeflow 파이프라인 템플릿

서비스 계정 사용:

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

3. Artifact Registry로 인증하도록 타사 클라이언트를 구성합니다.

   • 컨테이너 이미지: Docker, Helm
   • 언어 패키지: Java, Node.js, Python, Go
   • OS 패키지: Debian, RPM
   • 기타: Kubeflow 파이프라인 템플릿

Google Cloud의 GitLab

Google Cloud의 GitLab 통합은 서비스 계정이나 서비스 계정 키 없이 Google Cloud의 GitLab 워크로드에 대한 승인 및 인증을 위해 워크로드 아이덴티티 제휴를 사용합니다. 이 파트너십에서 워크로드 아이덴티티 제휴를 사용하는 방법은 Google Cloud 워크로드 아이덴티티 제휴 및 IAM 정책을 참조하세요.

Google Cloud의 GitLab에 워크로드 아이덴티티 제휴 및 필요한 IAM 역할을 설정하려면 GitLab 튜토리얼 Google Cloud 워크로드 아이덴티티 제휴 및 IAM 정책을 참조하세요.

Artifact Registry 저장소를 연결하려면 GitLab 튜토리얼 Google Artifact Registry를 따르세요.

역할 및 권한

모든 Artifact Registry API 메서드에는 요청을 실행하는 주 구성원에게 리소스를 사용하는 데 필요한 권한이 있어야 합니다. 주 구성원에게 리소스에 대한 사전 정의된 역할을 부여하는 정책을 설정하여 주 구성원에게 권한을 부여합니다.

Google Cloud 프로젝트 또는 Artifact Registry 저장소에 역할을 부여할 수 있습니다.

사전 정의된 Artifact Registry 역할

IAM은 특정 Google Cloud 리소스에 대한 액세스 권한을 부여하는 사전 정의된 역할을 제공합니다.

pkg.dev 도메인의 저장소에 다음과 같은 사전 정의된 역할을 사용합니다.

기본 IAM 역할

기본 역할은 IAM 도입 전에도 있었던 높은 권한이 있는 역할입니다. 프로덕션 환경에서는 기본 역할을 부여하지 말아야 하지만 개발 환경 또는 테스트 환경에서는 부여해도 됩니다.

사용자 및 서비스 계정에 필요한 권한만 포함되도록 가능한 모든 경우에 저장소 액세스에 대해 사전 정의된 역할을 사용하세요.

기본 역할에 대한 자세한 내용은 IAM 기본 및 사전 정의된 역할 참조를 확인하세요.

역할 부여

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

gcloud 명령어를 사용하여 역할을 부여하는 경우 주 구성원의 단일 역할 바인딩을 지정하거나 리소스의 허용 정책을 가져와 수정한 후 수정된 허용 정책을 설정하여 대규모 정책 변경을 수행할 수 있습니다. 자세한 내용은 프로그래매틱 방식으로 여러 역할 부여 또는 취소를 참고하세요.

프로젝트 전체 역할 부여

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

프로젝트에 사용자 또는 서비스 계정을 추가하고 Artifact Registry 역할을 부여하려면 다음 안내를 따르세요.

저장소별 역할 부여

프로젝트의 저장소마다 사용자 또는 서비스 계정에 다른 수준의 액세스 권한을 부여하려면 저장소 수준의 역할을 부여합니다.

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}"
}

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

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

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

역할 취소 중

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

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

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

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

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

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

• 태그 및 액세스 제어를 설정하는 관리자
  • 태그 생성 및 관리
  • 태그 및 액세스 제어
• 저장소에 태그를 연결하는 개발자
  • 저장소 태그하기

Google Cloud 서비스와 통합

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

Google Cloud 서비스의 기본 서비스 계정

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

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

• Google Cloud 서비스가 Artifact Registry와 다른 프로젝트에 있습니다.
• 기본 권한이 요구사항에 부합하지 않습니다.
• 기본 서비스 계정 대신 Artifact Registry와 상호작용하는 데 사용자 제공 서비스 계정을 사용합니다.
• 조직 정책 구성으로 인해 기본 서비스 계정에 대한 자동 역할 부여가 차단됩니다.

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

조직 정책 구성에 따라 프로젝트에 대한 편집자 역할이 기본 서비스 계정에 자동으로 부여될 수 있습니다. iam.automaticIamGrantsForDefaultServiceAccounts 조직 정책 제약조건을 적용하여 자동 역할 부여를 중지하는 것이 좋습니다. 2024년 5월 3일 이후에 조직을 만든 경우 기본적으로 이 제약조건이 적용됩니다.

자동 역할 부여를 중지한 경우 기본 서비스 계정에 부여할 역할을 결정한 후 직접 이러한 역할을 부여해야 합니다.

기본 서비스 계정에 이미 편집자 역할이 있으면 편집자 역할을 권한이 더 낮은 역할로 바꾸는 것이 좋습니다. 서비스 계정 역할을 안전하게 수정하려면 정책 시뮬레이터를 사용하여 변경사항의 영향을 확인한 후 적절한 역할을 부여하고 취소합니다.

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가 Artifact Registry와 동일한 프로젝트에 있습니다.
• 노드가 기본 서비스 계정인 Compute Engine 기본 서비스 계정을 사용 중입니다.
• 다음을 수행하여 노드가 스토리지 읽기 액세스로 생성되었습니다.
  • Compute Engine 기본 액세스 범위를 사용합니다.
  • cloud-platform 액세스 범위 또는 스토리지에 대한 읽기 액세스가 포함된 다른 범위를 부여합니다.
• 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 서비스 계정을 참조하세요.

다음 단계

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

• 컨테이너 이미지: Docker, Helm
• 언어 패키지: 자바, Node.js, Python, Go
• OS 패키지: Debian, RPM