This document describes the IAM permissions that are required to view Software Delivery Shield security insights. Software Delivery Shield is a fully-managed software supply chain security solution on Google Cloud.
Required roles
To view Software Delivery Shield insights in Google Cloud console, you must have the following roles, or a role with equivalent permissions:
- Cloud Build Viewer
(
roles/cloudbuild.builds.viewer
): View insights for a build. - Artifact Analysis Occurrences Viewer
(
roles/containeranalysis.occurrences.viewer
): View vulnerabilities, build provenance, and other dependency information. - Cloud Run Viewer (
roles/run.viewer
): View insights for a Cloud Run revision. - Kubernetes Engine Cluster Viewer (
roles/container.clusterViewer
): View insights for a GKE cluster.
These permissions provide access to insights, but they do not provide permissions to perform other actions such as running builds in Cloud Build.
- For details about required permissions for a specific service, refer to the documentation for that service.
- To learn about granting permissions, see the Identity and Access Management documentation on granting permissions to projects.
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 default Cloud Build 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.
- Cloud Run revisions use the Compute Engine default service account for 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 the required roles to 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 appropriate Artifact Registry permissions and Artifact Analysis permissions in 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.
- Artifact Registry Writer (
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.
- Artifact Registry Reader (
- User permissions to view insights
In project B, you must grant users of Cloud Build and Cloud Run with the required roles view insights.
What's next
- Learn more about Software Delivery Shield services in the overview
- Learn about software supply chain security practices and how Software Delivery Shield can help you to implement them.