Join Joseph Lowery for an in-depth discussion in this video Overview of Compute Engine authentication, part of Google Cloud Compute Engine Essential Training.
- Security is more important than ever these days. Not only do we want to make sure that only authorized persons are accessing certain data, we need to make sure that only authorized devices and systems can share information. In this chapter, we'll take a look at Compute Engine's authentication protocols and how they can protect you, and your app's data. For all Google Cloud, including Compute Engine, authentication is at its heart based on the OAuth 2.0 standard.
There are two basic ways that authentication can be applied with Compute Engine. By authorizing request from Compute Engine and by authorizing request to Compute Engine. Let's look at those requests coming from Compute Engine first. These types of authentication requests are typically requests to other Google Cloud services and there are two possible approaches that can be taken: the standard OAuth 2.0 workflow or by using Google service accounts.
OAuth 2 requests from Compute Engine. like all other such requests, are secure socket layer based rather than using external encryption/decryption techniques. A variety of applications can use this technique: web applications, installed or desktop applications, and Client-side applications. The typical workflow for using OAuth 2.0 to complete an authentication request takes four steps. Get your credentials, that's the project ID, from the console.
Get a token from the Google Authorization Server, send that token to the API via HTTP authorization header and then refresh the token as needed. We'll discuss these steps in more detail later in this chapter. The other technique for requesting authentication from Compute Engine is through service accounts. Service accounts are used for service to service requests. A service account is automatically created for every Computer Engine project.
They use internal encryption/decryption algorithms developed by Google rather than using the secure socket layer. The service account workflow is a bit more efficient than the OAuth 2 approach as it requires fewer steps to complete. Here's how a service account workflow is structured. First, a Compute Engine project is created, which automatically creates a service account, then the application submits a rest request to Google's metadata server and in return receives a token.
If it's authorized, of course. Finally, that token can be used to make requests from other Google Cloud API's and services. The other type of request, a request to Compute Engine, can only be handled through OAuth 2 protocols and follows the same workflow as the OAuth request from Compute Engine. In order for this request to be authorized we'll need to know the Client ID, the client secret, which is a secondary ID, occasionally required, and finally, you'll need to know the scope of the request such as read only, write only, or full access.
Authentication is a day to day, even minute to minute requirement of our computing lives. Compute Engine has a full, robust structure in place that handles such needs in a secure fashion.
- Integrating with Google Cloud products
- Setting up the Google Cloud SDK
- Creating a Compute Engine instance
- Authenticating users
- Working with Python and Compute Engine
- Managing resources
- Implementing network load balancing