Controlling application authentication and access. In the last lecture, we got our first peek at just how easy it can be to build and deploy Infrastructure as Code on Google Cloud Platform. Before we get too carried away though, we need to take a few minutes to learn about and better understand a few key GCP features we should be implementing in our IaC configurations that will both streamline authentication and improve our security. Identity and Access Management.

In the previous lecture group, we talked a little about layered security and principle of least privilege. We want each user to have their own credentials to each system they need access to, with only the minimum number of permissions they require. Google Identity and Access Management makes it considerably easier for us to do this all in one place. We can easily add a new member with a Google account to our project, and assign them any specific roles they need for access to the project, or to any Google resources the project uses. These roles can even be assigned conditionally, so you could grant a user permissions with an expiration date, or only grant them access to specific resources on certain days or between certain times.

Service Accounts. To improve security even further, we can create service accounts with Google IAM that our applications can use for authentication or access to any other Google resources. Unlike member accounts, service accounts have no password. They instead provide an easy way to embed service authentication into our application, without including any sensitive password data or credential files in our project source code at all.

We can add roles to the service account the same way as a member account, then reference the service account in our project code, and Google handles the rest. Sometimes when working with virtual machine instances or containerized environments, we won't be able to automatically authenticate these service account credentials with Google due to layers of abstraction in our application.

For these situations, we can add a key to our service account, either from the cloud console or as a gcloud command. When you do this, a new private key file will be create. Be sure to store it safely. This is the only time Google will ever give you this key, and there's no way to recover it if you lose it. You will have to create a new one instead. Each service account can have up to ten keys. We can then use this key from within our application images to authenticate with Google services using our service account.

Google Secret Manager. Including a key file for our service account in our project source code means we are once again storing sensitive data in our repository. We can avoid this by implementing Google Secret Manager into our project as well. We can upload our key file using the cloud console to create a new secret, then reference this secret to include the key into our build at runtime. We can also create and interact with secrets directly using gcloud commands.

Since Google Cloud Build is able to authenticate using our service account natively, we can easily access our secret data during the build process to embed it in our image where our application code can use it later. We just need to make sure that we give our service account permissions to access our secret. It's easiest to do this from the cloud console web interface, but can also be done from command line with gcloud commands.

Google Cloud Client Library. We've seen how to work with service accounts and secrets natively from the cloud console and gcloud command line. To interact with Google APIs from within our application will require that we include the Google Cloud Client Library in our project source code. In the example repository for this course, you can see where we have included the PHP version of the library here. This code authenticates our PHP application using our service account, and allows us to replace all of the sensitive data in our WordPress config file with secrets managed by Google Secret Manager instead.