Service Accounts
1. Service Accounts
As mentioned earlier, another type of member is a service account. A service account is an account that belongs to your application instead of to an individual end user. This provides an identity for carrying out service-to-service interactions in a project without supplying user credentials. For example, if you write an application that interacts with Cloud Storage, it must first authenticate to either the Cloud Storage XML API or JSON API. You can enable service accounts and grant read-write access to the account on the instance where you plan to run your application. Then, program the application to obtain credentials from the service account. Your application authenticates seamlessly to the API without embedding any secret keys or credentials in your instance, image, or application code. Service accounts are identified by an email address, like the example shown here. There are three types of service accounts: user-created or custom, built-in, and Google APIs service accounts. By default, all projects come with the built-in Compute Engine default service account. Apart from the default service account, all projects come with a Google Cloud APIs service account, identifiable by the email: [email protected]. This is a service account designed specifically to run internal Google processes on your behalf, and it is automatically granted the Editor role on the project. Alternatively, you can also start an instance with a custom service account. Custom service accounts provide more flexibility than the default service account, but they require more management from you. You can create as many custom service accounts as you need, assign any arbitrary access scopes or IAM roles to them, and assign the service accounts to any virtual machine instance. Let's talk more about the default Compute Engine service account. As I mentioned, this account is automatically created per project. This account is identifiable by the email: [email protected], and it is automatically granted the Editor role on the project. When you start a new instance using gcloud, the default service account is enabled on that instance. To override this behavior, you can specify another service account, or disable service accounts for the instance. Now, authorization is the process of determining what permissions an authenticated identity has on a set of specified resources. Scopes are used to determine whether an authenticated identity is authorized. In the example shown here, Applications A and B contain Authenticated Identities (or service accounts). Let's assume that both applications want to use a Cloud Storage bucket. They each request access from the Google Authorization server, and in return they receive an access token. Application A receives an access token with read-only scope, so it can only read from the Cloud Storage bucket. Application B, in contrast, receives an access token with read-write scope, so it can read and modify data in the Cloud Storage bucket. Scopes can be customized when you create an instance using the default service account, as shown in this screenshot. These scopes can be changed after an instance is created by stopping it. Access scopes are actually the legacy method of specifying permissions for your VM. Before the existence of IAM roles, access scopes were the only mechanism for granting permissions to service accounts. For user-created service accounts, use IAM roles instead to specify permissions. Roles for service accounts can also be assigned to groups or users. Let's look at the example shown on this slide. First, you create a service account that has the InstanceAdmin role, which has permissions to create, modify, and delete virtual machine instances and disks. Then you treat this service account as the resource, and decide who can use it by providing users or a group with the Service Account User role. This allows those users to act as that service account to create, modify, and delete virtual machine instances and disks. Users who are Service Account Users for a service account can access all the resources that the service account has access to. Therefore, be cautious when granting the Service Account User role to a user or group. Here is another example. The VMs running component_1 are granted Editor access to project_b using Service Account 1. VMs running component_2 are granted objectViewer access to bucket_1 using an isolated Service Account 2. This way you can scope permissions for VMs without re-creating VMs. Essentially, IAM lets you slice a project into different microservices, each with access to different resources, by creating service accounts to represent each one. You assign the service accounts to the VMs when they are created, and you don't have to ensure that credentials are being managed correctly because Google Cloud manages security for you. Now, you might ask, how are service accounts authenticated? There are two types of service account keys. By default, when using service accounts within Google Cloud, for example, from Compute Engine or App Engine, Google automatically manages the keys for service accounts. However, if you want to be able to use service accounts outside of Google Cloud, or want a different rotation period, it is possible to also manually create and manage your own service account keys. All service accounts have Google-managed key-pairs. With Google-managed service account keys, Google stores both the public and private portion of the key, and rotates them regularly. Each public key can be used for signing for a maximum of two weeks. Your private key is always held securely in escrow and is never directly accessible. You may optionally create one or more user-managed key pairs, also known as "external" keys, that can be used from outside of Google Cloud. Google only stores the public portion of a user-managed key. The user is responsible for security of the private key and performing other management operations such as key rotation, whether manually or programmatically. Users can create up to 10 service account keys per service account to facilitate key rotation. User-managed keys can be managed by using the IAM API, the gcloud command-line tool, or the Service Accounts page in the Google Cloud console. Google does not save your user-managed private keys, so if you lose them, Google cannot help you recover them. You are responsible for keeping these keys safe and also responsible for performing key rotation. User-managed keys should be used as a last resort. Consider the other alternatives, such as short-lived service account credentials (tokens), or service account impersonation. The gcloud command-line shown on this slide is a fast and easy way to list all of the keys associated with a particular service account.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.