[[["容易理解","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 (世界標準時間)。"],[],[],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."]]
