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.