Securing artifacts

This page describes Google Cloud services and features that help you to secure artifacts, as well as some best practices to protect your data.

Encryption at rest

By default, Google Cloud automatically encrypts data when it is at rest using encryption keys managed by Google. If you have specific compliance or regulatory requirements related to the keys that protect your data, you can create repositories encrypted with customer-managed encryption keys (CMEK).

Vulnerability scanning

Container Analysis can scan container images for security vulnerabilities in publicly monitored packages.

The following options are available:

Automatic vulnerability scanning
When enabled, this feature identifies package vulnerabilities in your container images. Images are scanned when they are uploaded to Artifact Registry and the data is continuously monitored to find new vulnerabilities for up to 30 days after pushing the image.
On-Demand Scanning API
When enabled, you can manually scan local images or images stored in Artifact Registry. This feature helps you to detect and address vulnerabilities early in your build pipeline. For example, you can use Cloud Build to scan an image after it is built and then block upload to Artifact Registry if the scan detects vulnerabilities at a specified severity level. If you also enabled automatic vulnerability scanning, Container Analysis also scans images you upload to the registry.

Deployment policy

You can use Binary Authorization to configure a policy that the service enforces when an attempt is made to deploy a container image to one of the supported Google Cloud environments.

For example, you can configure Binary Authorization to only allows deployments if an image is signed for compliance with a vulnerability scan policy.

Removing unused images

Remove unused container images to reduce storage costs and mitigate the risks of using older software. There are a number of tools available to help with this task, including gcr-cleaner. The gcr-cleaner tool is not an official Google product.

Shifting left on security

Integrating information security objectives into daily work can help increase software delivery performance and build more secure systems. This idea is also known as shifting left, because concerns, including security concerns, are addressed earlier in the software development lifecycle (that is, left in a left-to-right schedule diagram). Shifting left on security is one of the DevOps capabilities identified in the DORA State of DevOps research program.

To learn more:

  • Read about the Shifting left on security capability
  • Read the whitepaper Shifting left on security, which describes responsibilities, practices, processes, tools, and techniques that increase confidence in the software development lifecycle (SDLC) and reduce security-risk concerns.

Considerations for public repositories

Carefully consider the following cases:

  • Usage of artifacts from public sources
  • Making your own Artifact Registry repositories public

Using artifacts from public sources

Public sources of artifacts, such as GitHub Docker Hub, PyPI, or the npm public registry provide tools you might use or dependencies for your builds and deployments.

However, your organization might have constraints that impact your use of public artifacts. For example:

  • You want to control the content of your software supply chain.
  • You don't want to depend on an external repository.
  • You want to strictly control vulnerabilities in your production environment.
  • You want the same base operating system in every image.

Consider the following approaches secure your software supply chain:

  • Set up automatic builds so that your artifacts have consistent, known content. You can use Cloud Build build triggers or other continuous integration tools.
  • Use standardized base images. Google provides some base images that you can use.
  • Address vulnerabilities in your artifacts. You can use On-Demand Scanning API to scan container images for vulnerabilities before storing them in Artifact Registry. Container Analysis can also scan containers that you push to Artifact Registry.
  • Enforce your internal standards on image deployments. Binary Authorization provides enforcement for container image deployments to supported Google Cloud environments.

Learn more about considerations for public images

Public Artifact Registry repositories

You can make an Artifact Registry repository public by granting the Artifact Registry Reader role to the allUsers identity.

If all your users have Google Cloud accounts, you can limit access to authenticated users with the allAuthenticatedUsers identity instead.

Consider the following guidelines before making an Artifact Registry repository public:

  • Verify that all artifacts you store in the repository are sharable publicly and do not expose credentials, personal data, or confidential data.
  • You are charged for network egress when users download artifacts. If you expect a lot of internet download traffic, consider the associated costs.
  • By default, projects have unlimited per-user quota. To prevent abuse, cap per-user quota within your project.

Guidance for web applications

  • The OWASP Top 10 lists the top web application security risks according to the Open Web Application Security Project (OSWAP).

Guidance for containers

  • Best practices for building containers includes recommendations for building containers.

    You can also read the Docker best practices for building images.

  • Best practices for operating containers includes recommendations for security, monitoring, and logging that make applications easier to run in Google Kubernetes Engine and in containers in general.

  • The Center for Internet Security (CIS) has a Docker Benchmark for evaluating the security of a Docker container.

    Docker provides an open source script called Docker Bench for Security. You can use the script to validate a running Docker container against the CIS Docker Benchmark.

    Docker Bench For Security can help you verify many items in the CIS Docker Benchmark, but not all items are verifiable with the script. For example, the script cannot verify if the host for the container is hardened or if the container image includes personal data. Review all items in the benchmark and identify those that might need additional verification.