Getting Started with Infrastructure as Code
Securing IaC Deployments on GCP
Deploying Infrastructure as Code on GCP
The course is part of these learning paths
Learn how to simplify all of your application infrastructure into just a few configuration files then deploy your code on Google Cloud Platform with this course. We will start by learning the core concepts behind Infrastructure as Code, discussing security best practices when working with IaC, and comparing some popular orchestration and configuration management tools.
After that, we’ll implement version control for our IaC configurations, and learn how we can automate deployment updates using Cloud Build Triggers. Next, we’ll learn how to integrate Google Secret Manager to protect any sensitive data in our source code. Then to tie it all together, we’ll walk through Google Identity and Access Management and learn how to monitor our users and resources on GCP.
After learning the basics, we’ll build our own immutable server images with Google Cloud Build using both Docker and Packer. We’ll then explore a practical usage scenario and build a WordPress deployment with Google Deployment Manager. We’ll also deploy a similar WordPress configuration using Terraform to compare the two methods.
I will be working in Visual Studio Code during the demos for this course, but you are also free to use any other IDE you are comfortable with instead. A demo repository is provided along with this course, and while we will be working with some Python and PHP in our examples, you should still be able to follow along with the demos without any background in either of these languages.
- Build server images from a configuration file using Docker and Packer.
- Learn to use Google Cloud Build with third-party build steps.
- Deploy application infrastructure from code using Google Deployment Manager and Terraform.
- Understand templating systems for Infrastructure as Code.
- Implement version control for Infrastructure as Code.
- Learn to protect secret data in IaC configurations using Google IAM role management and Google Secret Manager.
This course is intended for programmers interested in expanding their knowledge about modern cloud-based DevOps workflows. Learning to manage Infrastructure as Code is beneficial to solo developers who need to focus as much of their time as possible on their application code and not on managing infrastructure. Development teams will also benefit from this course, because implementing IaC provides consistent performance across deployments in multiple environments, which greatly simplifies project collaboration. This course will also help prepare the viewer for the Google Professional Cloud DevOps Engineer certification.
- You should already have a Google Cloud Platform account.
- You should have Google Cloud SDK already installed and initialized.
- You should already have Git installed, and be familiar with its use.
- Demos will be shown in Visual Studio Code, but you're free to use any IDE they are familiar with.
- Demos will utilize some Python and PHP, but you're not required to be fluent in either of these languages to follow along with the examples.
Implementing Security Best Practices on Cloud Infrastructure. We have previously discussed how a DevOps workflow that implements infrastructure as code can greatly streamline and simplify both development and operations. What we haven't talked about much yet is how it can actually quickly become kind of a nightmare for security and compliance without some forethought and planning early on in your application design. Let's go over some best practices to keep in mind from the very beginning of your infrastructure as code project so you can avoid encountering these difficulties later.
Using principle of least privilege. It can be very tempting to just give developers administrative rights in their development environments as a convenience so they don't have to worry about things like permission issues disrupting their workflow. This is an especially dangerous practice when working with infrastructure as code however. If the developer's password is compromised, not only is the application compromised, but so might be the entire server and network it runs on.
The principle of least privilege tells us to supply each user with only the bare minimum level of permissions required to perform their job. This practice can be very tedious to deploy at first, as you have to accurately define all the minimum permissions required for each role in your entire organization. These permissions can be centrally managed with Google using IAM to make this job a little easier, which we'll talk about more towards the end of this course.
Building layered security. Related to our principle of least privilege, we want to manage security for all of the different systems and services that make up our application as their own individual entities, rather than thinking of application security as one singular unit. As an example, a WordPress application will have a PHP service running on Apache connected to a SQL database instance. Our WordPress admin would require a number of different credentials: an operating system login with permission to manage the Apache instance and WordPress files, SQL user credentials with access to the database, and login credentials for WordPress itself, just to name a few.
Ideally, we want to issue every user their own credentials to each of these systems and services, allowing them only the minimum permissions required on each, as per the principle of least privilege. This way, if any one password is compromised, the impact will be minimal and the problem can be isolated quickly. We never want to just bake default credentials into our configurations. Obviously, this can become a large number of credentials to manage very quickly, and increases exponentially with additional users.
Just like using principle of least privilege, implementing layered security is rather tedious. We're saving a lot of time with our improvements made in development and operations using infrastructure as code, so we can afford to put a little of that time back in by making sure we are implementing proper security. If good security practices were convenient to use, then nobody would ever have bad security practices and we wouldn't be talking about it right now. Good security often boils down to just doing things the right way instead of the easy way.
Encrypting and restricting sensitive data. It may seem obvious to say you shouldn't store your username and password information in any plain text configuration files. Yet there are other types of data like API keys or environment variables that developers may routinely use which are still sensitive in nature, but are often left exposed in their source code. Using infrastructure as code, we can turn these sensitive data points into variables in our configuration and then load that variable data from a secure and encrypted source like Google Secret Manager. We can, in this way, control which users or service accounts have access to specific credentials using Google IAM roles. This helps tie together our security management for our GCP deployments all in one place.
Arthur spent seven years managing the IT infrastructure for a large entertainment complex in Arizona where he oversaw all network and server equipment and updated many on-premise systems to cloud-based solutions with Google Cloud Platform. Arthur is also a PHP and Python developer who specializes in database and API integrations. He has written several WordPress plugins, created an SDK for the Infusionsoft API, and built a custom digital signage management system powered by Raspberry Pis. Most recently, Arthur has been building Discord bots and attempting to teach a Python AI program how to compose music.