Locking Down Access to Production
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

With container analysis, binary authorization, and a little glue code, you can start building a pretty secure deployment pipeline. But there's still one last issue to consider. What about direct modification to production? The most secure pipeline in the world is useless if a user can simply bypass it all.

For example, let's say you wanted to increase physical security at your workplace. You would not want everyone's security badge to be granted the same level of access. Certain employees would have access to certain rooms. Security might have the keys to the front door but not necessarily to the server room. Operations might be allowed to go inside the server room but not allowed into the CEO's office. Each employee should be given just enough access to do their job and no more. This is the principle of least privilege. And it should work the same way in the cloud.

Your employee's access to your Google cloud resources should be based upon what they require to do their job. It is pretty standard for developers and QA engineers to be allowed to deploy containers to certain existing clusters but not allowed to create new clusters. Infrastructure engineers might be able to create and delete clusters, but not actually deploy images to them.

The security team might be able to change firewall rules and create SSL certificates inside each cluster but nothing else. The exact permissions will vary based upon the needs of the company. It really depends upon the number of roles, steps, and environments that exist. A small company with a few engineers might just have two environments like staging and production, and a very basic pipeline.

In this case, each user and component will probably need to have a lot of permissions. Because each part is responsible for doing many things. But in a large company with hundreds or thousands of engineers things might be totally different. There could be multiple environments such as development, testing, user acceptance, staging, and production. And the deployment pipeline might have many, many steps. In this case each individual and component can have a much smaller set of permissions because they're responsible for much less.

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.