Safeguard deployments

This document describes best practices for protecting your deployments.

Create and enforce deployment policies

To protect your runtime environments, define policies with criteria for deployment and validate policy compliance before and after deployment. Defining a policy that only allows code signed by predefined attestors helps in gating deployments and deploying only code from trusted origins.

Examples of deployment criteria include:

  • No known vulnerabilities with a severity above Medium
  • Source code is from a trusted source repository
  • A trusted build service ran the build
  • Build artifacts you are deploying are from a trusted artifact repository

Generate metadata

To validate these requirements, your need to provide metadata about your build artifacts.

Build origins

Build provenance is a collection of verifiable data about a build such as the digests of built images, the input source locations, the build toolchain, and the build duration. SLSA, a framework for assessing security posture, provides a model for provenance and requirements for provenance. Provenance is one requirement category in the framework, and each requirement is associated with SLSA levels so that you can incrementally implement mitigations.

  • For SLSA level 1 assurance, provenance must be available.
  • For SLSA level 2 assurance, provenance must be generated and consumers must be able to verify its authenticity and integrity.
  • SLSA Levels 3 and 4 have stricter requirements for provenance signing and depth of provenance data detail.

Some build services generate build provenance metadata.

Vulnerabilies

Vulnerability scanning software checks your source code and build artifacts for known vulerabilties. Artifact Analysis can automatically scan container images pushed to Artifact Registry for vulnerabiilities. To check artifacts for vulnerabilities before you store them, you can use the On-Demand Scanning API in a local development environment or in a CI/CD pipeline, such as a Cloud Build build step.

Set up policy enforcement

Once you have metadata about your deployable artifacts, you need tools to enforce your policies.

In Google Cloud, you can configure a policy in Binary Authorization for your deployments. Binary Authorization enforces policy for attempted deployments to supported container-based platforms. It can also perform continuous validation of policy for workloads running on GKE, Cloud Run, and GKE Enterprise.

Pre-deployment checks can block all images that are not in the exempt image list, so that only trusted images are deployed from trusted registries. Your policy can also require attestations, digital documents that signify that the image was built successfully with a specific, required process. For example an attestion can indicate that an image is:

Continuous validation extends policy validation to the post-deploy environment. When enabled, Binary Authorization provides validation throughout the Pod lifecycle by regularly logging policy conformance in Cloud Logging. This is useful in a variety of situations. For example, if you change your policy after deploying a container, continuous validation logs Pods that violate te updated policy. It also logs policy violations for Pods deployed with dry run or breakglass.

Use gated deployment services

Deployment gating lets you approve or deny deployments at specific points in the deployment process using a standalone CI/CD service or a CI/CD service integrated with a process automation system. Gated deployments prevent unauthorized users from making changes to application environments. They provide additional oversight to the deployment process and greater visibility of approvals.

In Google Cloud, Cloud Deploy offers a fully-managed service for deploying workloads to Google Kubernetes Engine. The gated deployment feature lets users specify if an approval is needed for promotion to a target.

Monitor your workloads

Workloads are applications running on container-based platforms such as GKE and Cloud Run. The workloads that you deploy should ideally have a hardened configuration that limits their attack surface.

Checking workloads across clusters for configuration issues can be difficult to do manually at scale. Google Cloud provides dashboards in Cloud Run and GKE to view security insights for workloads.

The GKE security posture dashboard provides you with guidance to strengthen the security posture of your clusters based on Google's recommendations. It includes automatic workload configuration scanning, which checks for known configuration concerns across all workloads. GKE checks each deployed workload against relevant industry best practices, such as policies in the Pod Security Standards. GKE rates the severity of discovered issues and returns actionable recommendations and logs. You can use Cloud Logging to get an auditable trail of concerns for better reporting and observability. For instructions on viewing security insights in the GKE security posture dashboard, see Deploy on GKE and view security insights.

Cloud Run contains a security panel that displays software supply chain security insights such as the SLSA build level compliance info, build provenance, and vulnerabilities found in running services. For instructions on viewing security insights in the Cloud Run security insights panel, see Deploy on Cloud Run and view security insights.

Google Cloud also provides other services and features to improve your security posture across the software development lifecycle. For more information, see the software supply chain overview.

What's next