As I 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 server-to-server
interactions in a project without supplying
user credentials. For example, if you write an application that interacts
with Google Cloud Storage, it must first authenticate to either the Google 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 authenticate
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 the Google Cloud Platform APIs service account, identifiable by the email,
project-number@cloudservices.gserviceaccount.com. This is the service account
designed specifically to run internal Google
processes on your behalf, and it is automatically granted the editor role on your
project. Alternatively, you can also start an instance with
accustomed 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 Cloud 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, project-number-compute@developer.gserviceaccount.com,
and it is automatically granted the editor
role on a project. When you start a new
instance using GCloud, the default service account
is enabled on that instance. You can override this
behavior by specifying another service account or by disabling 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 in. 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 Cloud IAM roles instead
to specify permissions. Another distinction between
service accounts is that default service
account support both primitive and
predefined roles. But user-created service accounts only use predefined IAM roles.
Now, roles for
service accounts can also be assigned to
groups or users. Let's look at the example
shown on this slide. First, you created
a service account that has the instance admin 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 of 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 object viewer access to bucket one using an
isolated Service Account 2. This way you can
scope permissions for VMs without recreating VMs. Essentially, Cloud 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 the
credentials are being managed correctly because GCP
manages security for you. Now, you might ask, how are the service accounts
authenticated? Although users require a username and password to authenticate,
service accounts use keys. There are two types of
service account keys: GCP-managed keys and
user-managed keys. GCP-managed keys are
used by GCP services, such as App Engine
and Compute Engine. These keys cannot be downloaded, and are automatically rotated
and used for a
maximum of two weeks. User-managed keys are created, downloadable, and
managed by users. When you create a new key pair, you download the private key,
which is not retained by Google. With user-managed keys, you are responsible
for security of the private key and other
management operations such as key rotation, which is illustrated
on this slide.