By default, many services have default permissions for other services in the
same project but cannot access resources in another project.
If you are running services in different Google Cloud projects or
if you are using custom IAM roles or custom service accounts,
you must grant the appropriate permissions yourself.
Granting permissions when services are in the same project
If Cloud Build, Artifact Registry, Artifact Analysis, and
Cloud Run are all running in the same project, each service uses the
default service account to act on behalf of the service, and the default
permissions are unchanged. The services can all work together without changes
to permissions, but you do need to grant permissions to users that need to see
insights in the project.
Permissions between services
No changes are required:
The defaultCloud Build service
accounthas 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.
Cloud Run revisions use theCompute Engine default
service
accountfor deployments, which has permissions to download images from
Artifact Registry and read insight data from Artifact Analysis.
User permissions to view insights
You must grant users of Cloud Build and
Cloud Run with therequired rolesto view insights.
Granting permissions when services are in different projects
When Artifact Registry and Artifact Analysis are running in
separate project from other Google Cloud services, you must explicitly
grant permissions for all cross-project activity. Consider the following project
setup:
Cloud Build runs in project A
Artifact Registry and Artifact Analysis run in project B
Cloud Run runs in project C
Permissions between services
Cloud Build and Cloud Run cannot access resources in other
projects without explicitly granting access to the service accounts that act on
behalf of these services. You must grant appropriateArtifact Registry
permissionsandArtifact Analysis
permissionsin project B where the
artifacts and artifact metadata are stored.
For Cloud Build, you must grant these roles in project B:
Artifact Registry Writer (roles/artifactregistry.writer) grants permissions
to upload and download.
Artifact Analysis Occurrences Viewer
(roles/containeranalysis.occurrences.viewer) grants permissions to
display insights.
For Cloud Run, you must grant these roles in project B:
Artifact Registry Reader (roles/artifactregistry.reader) grants permissions
to download for deployments.
Artifact Analysis Occurrences Viewer
(roles/containeranalysis.occurrences.viewer) grants permissions to
display insights.
User permissions to view insights
In project B, you must grant users of Cloud Build and
Cloud Run with therequired rolesview insights.
What's next
Learn more about how Google Cloud services protect your software supply
chain in theoverview
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 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."]]
