Hello and welcome. In this lesson, we'll be looking at service accounts. Specifically, we're going to cover the topics listed in the exam guide, which are creating a service account with the minimum number of scopes, and downloading and using a service account private key file.

Service accounts are designed to allow non-humans to interact with GCP APIs. Regular accounts are intended for humans: they have a username, they have a password and a set of permissions that define which actions that user is allowed to perform. Service accounts are similar, though they have a few differences. Each service account has an email address that represents the identity, though rather than passwords, RSA keys are used, and there are two types of keys. We have Google-managed and user-managed. Google-managed keys are short-lived, automatically-rotated keys, which are used by Google Cloud Platform when a service interacts with the Google Cloud API as that service account. As an example, Compute Engine instances can be run as a service account, allowing applications such as gcloud to assume the identity of the service account. So, Google-managed keys are used by GCP services to interact with other GCP services.

User-managed keys are used by code running outside of GCP. Upon creating a key, Google stores the public key on our behalf, and it allows us to download the private key. Because the private key is not stored anywhere inside GCP, if lost, will require a new key to be generated. After we have a key generated, it can be deployed alongside whatever code requires it. Ideally, it would be deployed following the standards used by the application default credentials, which checks for an environment variable called GOOGLE_APPLICATION_CREDENTIALS, and that should point to the service account key file.

Since a service account is a type of account, we have to manage its permissions, which is done via IAM roles. These days, IAM roles offer a rather granular set of permissions. In the old days, however, there were only a few roles, which were really too permissive or not permissive enough. So, if we start up a Compute Engine instance to run under a service account, and it takes on the permissions of that account, using the old-style roles, we would have either too much permission or not enough. So, to ensure that instances run with the least amount of permissions possible, Google created access scopes.

Access scopes used to be the primary way of limiting permissions. They're now deprecated as a means of limiting instance permissions in favor of roles. However, they do still remain in effect and are required when launching an instance as a service account. Since roles are the current best practice for managing permissions, the current recommendation by Google is to use the cloud-platform scope, giving that scope ultimate permissions, and then limiting those permissions using IAM roles. And since there's really not much else to talk about with service accounts, that is gonna wrap up this lesson. 

Thank you so much for watching, and I will see you in another lesson.