Securing Cloud Run Deployments with Binary Authorization

Running applications and workloads in containers is becoming a standard practice for most organizations, especially organizations running in the cloud. This is due to the many benefits of designing applications as microservices. These benefits include increased scalability, better resiliency, faster deployments etc. As a result of this new ability to develop and push features faster, application and security teams are facing new challenges enforcing governance and control without hindering development speed. 

One common use case by customers is the ability to maintain different levels of governance for application artifacts depending on the environment. Developers have more autonomy in pre-production environments for deploying image artifacts but production releases may need to be deployed from a centralized and authorized artifact repository. With Binary Authorization and Artifact Registry, organizations can easily define the right level of control for different environments, and meet the strictness of their maturity in a SLSA journey or industry.

Cloud Run and Google Kubernetes Engine are two popular runtimes for containerized workloads on Google Cloud. Both are integrated with Binary Authorization and Artifact Registry to support improved end-to-end security. To focus on the simplicity of the solution, this blog will focus on Cloud Run. Before outlining the process, we need to understand what Artifact Registry and Binary Authorization are and how they fit into the Google Cloud ecosystem.

What is Artifact Registry?

Artifact Registry is the recommended service for storing and distributing images and application artifacts in Google Cloud. It provides a single location for storing and managing your packages and Docker container images. Artifact Registry integrates with Cloud Build and other continuous delivery and continuous integration systems to store packages from your builds. You can also store trusted dependencies that you use for builds and deployments. 

What is Binary Authorization?

Binary Authorization is a service on Google Cloud that provides software supply-chain security for container-based applications. It enables you to configure a policy that the service enforces when an attempt is made to deploy a container image on one of the supported container-based platforms. It provides an extra layer of security control to ensure only approved container images are deployed on the container platform services like Cloud Run and GKE.

Setting Up Deployment Controls

Now that we are familiar with these services, we can outline how they can be used in conjunction with Cloud Run for enforcing governance control for application deployments.

A best practice is to determine the scope of governance control for the organizational policy and the binary authorization policy. The organizational policy lets you define if Binary authorization is required on a specific project e.g. the production project, or on all projects in a specific folder or organization. The Binary Authorization policy grants users the flexibility to enforce deployment from a specific authorized repository in Artifact Registry or from all repositories in an authorized project e.g. the production project . A common use case will be to enforce the organizational policy on a specific project and the binary authorization policy to a single repository.

Step 1: Create a centralized repository in Artifact registry

Step 2: Require Binary Authorization for Cloud Run

To require every Cloud Run service to use Binary Authorization policies, you need to configure the “Allowed Binary Authorization Policies (Cloud Run)” organizational policy. This can be enforced at the Organization, Folder or Project Level depending on your scope. This ensures that no Cloud Run service deployed is capable of bypassing the binary authorization policy from being enforced. 

Step 3: Create a Binary Authorization Policy 

Binary Authorization Policies are created per project. Currently, you can only configure one policy per project. Policies should be customized based on the sensitivity of the environment running in a given project. Development projects may have no policies defined at all. Testing or staging projects may disallow all images by default with an exemption policy to allow deployments from one or more approved repository locations. Container images that match the image patterns of the exemption policy are allowed to be deployed to Cloud Run. Production projects may have a similar policy to staging with an additional requirement that all images be signed and attested by an authority within the organization. 

While the policy syntax can account for wide diversity of scenarios, as a starting point we can consider the policy rule to only allow images from a specific repository using a fully qualified resource name:

Check out the reference pages for creating exemption image patterns for Cloud Run and GKE

Step 4: Proactively monitor Cloud Audit Logs for “Break Glass” events

An attempt to deploy a Cloud Run service that violates the Binary Authorization organization policy configured earlier will result in an error. This error details the violation and gives the option to “break glass”. This allows users with the right permissions to override the Binary Authorization policy in place. Every Break Glass event is logged to Cloud Audit Logs, regardless of whether the deployment satisfies or violates the policy. Administrators can proactively configure notification of any Break Glass event to the appropriate channels using Log-based alerts in the Cloud Operations suite.

Conclusion

With Artifact Registry and Binary Authorization, Google Cloud users now have a flexible additional layer of security for better governance of container images. They also have better administration of control on what can be deployed across their container runtime environments. As shown above, organizations can deploy a range of basic to advanced policies depending on the maturity of their security posture or the requirements for different environments. The implementation outlined above can be applied for Google Kubernetes Engine and Anthos deployments with some additional Binary Authorization settings available like continuous validation, specific rules and Google system image exemption. You can find more information on Binary Authorization in our docs.