If you are building an application outside Google Cloud, a service account will be used to interact with Google Cloud services. You will need a way to authenticate with this account. It doesn’t come with a password, so an alternative could be to generate an RSA public/private key pair. The following screenshot shows how to achieve this in the Google Cloud console:
Figure 12.38 – Creating a key pair for a service account
Service account key details are presented in the KEYS tab when selecting a service account. You can create a new pair by selecting ADD KEY. Note that you can download a private key only during the key pair’s creation.
Access to a file with a key is sufficient to authenticate as a service account that owns the key. In the example that follows, the gcloud auth activate-service-account <service account> –key-file=<path/key> –project=PROJECT_ID command is used in vm-a that could even be running on-premises, followed by a command that creates a storage bucket. The service account – bucket-access – is the one that interacts with the Google Cloud Storage service from outside of a project:
Figure 12.39 – Using a service account with a key
As a downloaded key could be easily shared between users and possibly exposed, it is recommended to consider alternative options. When there is no other option, rotating keys frequently is highly recommended. One of the alternatives would be to use workload identity federation and give external identities permission to impersonate a service account and generate short-lived credentials for the application. You can find more information on workload identity federation at https://cloud.google.com/iam/docs/workload-identity-federation.
Let’s examine the other alternative, the token generation process, to better understand the benefits of short-lived credentials.
The gcloud auth print-access-token command returns a short-lived OAuth 2.0 access token that can be used for API calls on behalf of this user. In particular, the gcloud auth print-access-token –impersonate-service-account=<service_acount> command (assuming the Service Account Token Creator role is granted for the requester on a privilege-bearing service account) will return a short-lived (one hour by default) access token for a service account. Like a bucket-access account, a service account can have fine-grained permissions required for controlled interaction with a single service only, like Google Cloud Storage. In addition, the limited lifetime of a token minimizes the threat of it falling into the wrong hands, as could happen to a key.
Look at the following example. Details of a token generated by gcloud auth print-access-token can be validated using an HTTPS POST request: https://oauth2.googleapis.com/tokeninfo?access_token=<ACCESS_TOKEN>.
Figure 12.40 – Checking details about a token via HTTPS POST
An application can use a new token for an hour to interact with Google Cloud Storage as the token generated for a bucket-access service account, the one with the Storage Admin role assigned:
Figure 12.41 – Creating a bucket via API using an access token
The logic described is usually implemented programmatically and embedded into the code of an application. Client libraries handle token management.
Note that the number of service accounts for a project is limited by quotas. By default, you can create up to 100 service accounts. A good security practice is to remove any unused accounts. Since the number of service accounts can increase over time, it can become challenging to manage them, especially when multiple applications use them only occasionally. In case you are unsure if an application still uses a service account that you are about to delete, disable it first and ensure it is not used before deleting it.
Now that we have learned how to create users, groups, and service accounts and control their access to various Google Cloud resources, it is important to highlight that those tasks are just the first step in securing your environment. The next step is to find a way to make sure all permissions are assigned correctly and the desired setup is preserved. Also, if certain permissions are assigned, it is still important to know whether they were used with good and justified intentions. The next section will introduce the audit logging concept, which helps to track access and changes to your Google Cloud environments.