이러한 권한은 통계에 대한 액세스를 제공하지만 Cloud Build에서 빌드를 실행하는 등의 다른 작업을 실행할 권한은 제공하지 않습니다.
특정 서비스에 필요한 권한에 대한 자세한 내용은 해당 서비스의 문서를 참고하세요.
권한 부여에 대한 자세한 내용은 프로젝트에 권한 부여에 대한 Identity and Access Management 문서를 참조하세요.
기본적으로 많은 서비스에는 동일한 프로젝트의 다른 서비스에 대한 기본 권한이 있지만 다른 프로젝트의 리소스에는 액세스할 수 없습니다.
다른 Google Cloud 프로젝트에서 서비스를 실행하거나 맞춤 IAM 역할 또는 맞춤 서비스 계정을 사용하는 경우 적절한 권한을 직접 부여해야 합니다.
서비스가 동일한 프로젝트에 있는 경우 권한 부여
Cloud Build, Artifact Registry, Artifact Analysis, Cloud Run이 모두 동일한 프로젝트에서 실행되는 경우 각 서비스가 기본 서비스 계정을 사용하여 서비스를 대신하여 작동하며 기본 권한은 변경되지 않습니다. 권한을 변경하지 않아도 서비스가 모두 함께 작동할 수 있지만 프로젝트에서 통계를 확인해야 하는 사용자에게는 권한을 부여해야 합니다.
서비스 간 권한
변경하지 않아도 됩니다.
기본 Cloud Build 서비스 계정에는 Artifact Registry로 업로드 및 다운로드하고 Artifact Analysis에서 통계 데이터를 읽을 수 있는 권한이 있으므로, 서비스가 빌드 출처로 컨테이너 이미지에 서명하고 Artifact Registry로 내보낼 수 있습니다.
Cloud Run 버전은 배포에 Compute Engine 기본 서비스 계정을 사용합니다. 이 계정에는 Artifact Registry에서 이미지를 다운로드하고 Artifact Analysis에서 통계 데이터를 읽을 수 있는 권한이 있습니다.
통계를 볼 수 있는 사용자 권한
Cloud Build 및 Cloud Run 사용자에게 통계를 볼 수 있는 필수 역할을 부여해야 합니다.
서비스가 서로 다른 프로젝트에 있는 경우 권한 부여
Artifact Registry 및 Artifact Analysis가 다른 Google Cloud 서비스와 별도의 프로젝트에서 실행되는 경우 모든 프로젝트 간 활동에 대한 권한을 명시적으로 부여해야 합니다. 다음 프로젝트 설정을 고려하세요.
Cloud Build가 프로젝트 A에서 실행됨
Artifact Registry 및 Artifact Analysis가 프로젝트 B에서 실행됨
Cloud Run이 프로젝트 C에서 실행됨
서비스 간 권한
Cloud Build 및 Cloud Run은 이러한 서비스를 대신하여 작동하는 서비스 계정에 액세스 권한을 명시적으로 부여하지 않으면 다른 프로젝트의 리소스에 액세스할 수 없습니다. 아티팩트와 아티팩트 메타데이터가 저장된 프로젝트 B에 적절한 Artifact Registry 권한과 Artifact Analysis 권한을 부여해야 합니다.
Cloud Build의 경우 프로젝트 B에서 다음 역할을 부여해야 합니다.
Artifact Registry 작성자(roles/artifactregistry.writer)는 업로드 및 다운로드 권한을 부여합니다.
Artifact Analysis 어커런스 뷰어(roles/containeranalysis.occurrences.viewer)는 통계를 표시할 수 있는 권한을 부여합니다.
Cloud Run의 경우 프로젝트 B에서 다음 역할을 부여해야 합니다.
Artifact Registry 리더(roles/artifactregistry.reader)는 배포를 위해 다운로드할 수 있는 권한을 부여합니다.
Artifact Analysis 어커런스 뷰어(roles/containeranalysis.occurrences.viewer)는 통계를 표시할 수 있는 권한을 부여합니다.
통계를 볼 수 있는 사용자 권한
프로젝트 B에서는 Cloud Build와 Cloud Run 사용자에게 통계를 볼 수 있는 필수 역할을 부여해야 합니다.
다음 단계
개요에서 Google Cloud 서비스가 소프트웨어 공급망을 보호하는 방법 자세히 알아보기
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Configure access\n\nThis document describes the IAM permissions that are required to\nview software supply chain security insights in Google Cloud console.\n\nRequired roles\n--------------\n\nTo view software supply chain security insights in\nGoogle Cloud console, you must have the following roles, or a role\nwith equivalent permissions:\n\n- [Cloud Build Viewer](/iam/docs/understanding-roles#cloudbuild.builds.viewer) (`roles/cloudbuild.builds.viewer`): View insights for a build.\n- [Artifact Analysis Occurrences Viewer](/iam/docs/understanding-roles#containeranalysis.occurrences.viewer) (`roles/containeranalysis.occurrences.viewer`): View vulnerabilities, build provenance, and other dependency information.\n- [Cloud Run Viewer](/iam/docs/understanding-roles#run.viewer) (`roles/run.viewer`): View insights for a Cloud Run revision.\n- [Kubernetes Engine Cluster Viewer](/iam/docs/understanding-roles#container.clusterViewer) (`roles/container.clusterViewer`): View insights for a GKE cluster.\n\nThese permissions provide access to insights, but they don't provide permissions\nto perform other actions such as running builds in Cloud Build.\n\n- For details about required permissions for a specific service, refer to the documentation for that service.\n- To learn about granting permissions, see the Identity and Access Management documentation on [granting permissions to projects](/iam/docs/granting-changing-revoking-access).\n\nBy default, many services have default permissions for other services in the\nsame project but cannot access resources in another project.\nIf you are running services in different Google Cloud projects or\nif you are using custom IAM roles or custom service accounts,\nyou must grant the appropriate permissions yourself.\n\nGranting permissions when services are in the same project\n----------------------------------------------------------\n\nIf Cloud Build, Artifact Registry, Artifact Analysis, and\nCloud Run are all running in the same project, each service uses the\ndefault service account to act on behalf of the service, and the default\npermissions are unchanged. The services can all work together without changes\nto permissions, but you do need to grant permissions to users that need to see\ninsights in the project.\n\nPermissions between services\n\n: No changes are required:\n\n - The default [Cloud Build service\n account](/build/docs/cloud-build-service-account#default_permissions_of_service_account) has permissions to upload and download with Artifact Registry and read insight data from Artifact Analysis, so the service can sign container images with build provenance and push them to Artifact Registry.\n - Cloud Run revisions use the [Compute Engine default\n service\n account](/compute/docs/access/service-accounts#default_service_account) for deployments, which has permissions to download images from Artifact Registry and read insight data from Artifact Analysis.\n\nUser permissions to view insights\n\n: You must grant users of Cloud Build and\n Cloud Run with the [required roles](#permissions-insights)\n to view insights.\n\nGranting permissions when services are in different projects\n------------------------------------------------------------\n\nWhen Artifact Registry and Artifact Analysis are running in\nseparate project from other Google Cloud services, you must explicitly\ngrant permissions for all cross-project activity. Consider the following project\nsetup:\n\n- Cloud Build runs in project A\n- Artifact Registry and Artifact Analysis run in project B\n- Cloud Run runs in project C\n\nPermissions between services\n\n: Cloud Build and Cloud Run cannot access resources in other\n projects without explicitly granting access to the service accounts that act on\n behalf of these services. You must grant appropriate [Artifact Registry\n permissions](/artifact-registry/docs/access-control#permissions) and\n [Artifact Analysis\n permissions](/container-analysis/docs/ca-access-control) in project B where the\n artifacts and artifact metadata are stored.\n\n: For Cloud Build, you must grant these roles in project B:\n\n - Artifact Registry Writer (`roles/artifactregistry.writer`) grants permissions to upload and download.\n - Artifact Analysis Occurrences Viewer (`roles/containeranalysis.occurrences.viewer`) grants permissions to display insights.\n\n: For Cloud Run, you must grant these roles in project B:\n\n - Artifact Registry Reader (`roles/artifactregistry.reader`) grants permissions to download for deployments.\n - Artifact Analysis Occurrences Viewer (`roles/containeranalysis.occurrences.viewer`) grants permissions to display insights.\n\nUser permissions to view insights\n\n: In project B, you must grant users of Cloud Build and\n Cloud Run with the [required roles](#permissions-insights)\n view insights.\n\n What's next\n -----------\n\n- Learn more about how Google Cloud services protect your software supply chain in the [overview](/software-supply-chain-security/docs/overview)\n- Learn about [software supply chain security practices](/software-supply-chain-security/docs/practices) and how Google Cloud services can help you to implement them."]]
