Rejecting Unapproved Images
Start course

This course explores how to secure your deployment pipelines on GCP. We will cover the four main techniques to securely build and deploy containers using Google Cloud and you will follow along with guided demonstrations from Google Cloud Platform so that you get a practical understanding of the techniques covered.

If you have any feedback relating to this course, please contact us at

Learning Objectives

By completing this course, you will understand:

  • The advantages of using Google managed base images
  • How to detect security vulnerabilities in containers using Container Analysis
  • How to create and enforce GKE deployment policies using Binary Authorization
  • How to unauthorized changes to production using IAM

Intended Audience

This course is intended for:

  • Infrastructure/Release engineers interested in the basics of building a secure CI/CD pipeline in GCP
  • Security professionals who want to familiarize themselves with some of the common security tools Google provides for container deployment
  • Anyone taking the Google “Professional Cloud DevOps Engineer” certification exam


To get the most out of this course, you should be familiar with:

  • Building CI/CD pipelines
  • Building containers and deploying them to Kubernetes
  • Setting up IAM roles and policies

So now you know how to identify security vulnerabilities in your container images, but how do you actually prevent those compromised images from being used? Well, hopefully, someone doing a deployment would carefully check every image before deploying it, but you can't really rely on that.

Binary authorization is a deploy time security control that ensures only trusted container images are deployed onto Google Kubernetes Engine. Now, this is incredibly useful for preventing anyone from deploying a container image into production that: contain serious bugs or security issues, has not been approved for release, comes from an unapproved or unknown source, or was created by a malicious user.

Binary authorization enables you to either allow or block image deployment based upon the policies you define. So you can whitelist a trusted third party image not in cloud marketplace, or you can blacklist older versions of your product with known vulnerabilities. You can also leverage integrations with container analysis. For example, you can configure it to block images with one or more critical vulnerabilities in it. Or you could only allow images with a CVE severity score of less than five.

Now, as I said, with binary authorization, you define policies. These policies define certain attestations that must be present before an image can be deployed across your clusters. These policies can be used to ensure that your images follow the correct path through your deployment pipeline without skipping any steps.

At each checkpoint, you can create an attestation certifying that the image has correctly passed that check. Attestations can come from either automated systems or from people. So for example, you may want to ensure that your image has been scanned for vulnerabilities and that no anomalies turned up.

An automated system can watch your repository for new images, scan them, and then sign the images that pass using its cryptographic key. Or you may want to ensure that your image has been validated by your QA team. One of the QA team members could use their key to sign an attestation verifying that the image has successfully passed through QA.

Binary authorization also integrates with cloud audit logging to record failed pod creation attempts for later review. So anytime a deployment fails, you can figure out why. Also, if an unauthorized user attempts to deploy a blocked image, you will have an audit trail.

So far, this sounds great. But what about during an emergency, you say? What if I need to deploy a patch right now and I don't have time to go through all the normal channels? Well, binary authorization also has a break glass deployment feature. If you set the break glass flag for a deployment, you will be allowed to deploy an image even if it violates policy. However, audit logs will be recorded so that your incidence response team can review this deployment later. Now, with binary authorization, you have complete control over what checks need to happen before any image is deployed to one of your clusters.

About the Author
Learning Paths

Daniel began his career as a Software Engineer, focusing mostly on web and mobile development. After twenty years of dealing with insufficient training and fragmented documentation, he decided to use his extensive experience to help the next generation of engineers.

Daniel has spent his most recent years designing and running technical classes for both Amazon and Microsoft. Today at Cloud Academy, he is working on building out an extensive Google Cloud training library.

When he isn’t working or tinkering in his home lab, Daniel enjoys BBQing, target shooting, and watching classic movies.