GCP p12 files and service accounts – for accessing Storage Buckets, Google Drives and more

Service accounts are useful for a variety of GCP use cases.

A service account (email) is like a username.

1. If you are just using the service account within GCP, you DO NOT need the access key (it is known to GCP).
2. If you are using it to access GCP resources from outside of GCP, you need a way to authenticate yourself (a password of sorts, to go along with the service account). This password that goes along with the service account is essentially a private key (e.g. p12 key or JSON key). The key is created within the console so that GCP correctly associates it with the service account. 
3. Now that you know how to authenticate yourself to GCP, it is important to differentiate between two types of ‘passwords’ (access keys) – short term credentials and long term credentials.

Long lived service account credentials 

These are in the form of a p12 key file or a JSON key file. This post describes how to create these credentials. Once created within GCP, you will need to store them in an appropriate location on your local environment – e.g. within a trusted store for your product trying to access a GCP resource.

This post assumes the resource is a Google Drive (equally same instructions for a cloud storage bucket).

Short Lived Service Account Credentials – is basically OAuth or Open ID token based authentication against any GCP resource. The token has a limited lifetime (both Open ID and OAuth 2.0 have a 3600 seconds – 1 hour lifetime by default).

Creating Long Term Service Account Passwords ( Credentials  in the form of a p12 file or JSON file)

Step 1 – Add Credentials to Project (through IAM menu)

What Credentials do I need?

Create p12 format key (to be used as the password corresponding to the service account username)

That’s it. You should now have a p12 key file (this can be downloaded and added to local certificate stores – since it acts a s a client certificate).

What do you do with this key?

This p12 key serves as a client certificate (sort of) – and as such, can be added to the certificate store on a client desktop. Just as a client certificate is used to authenticate a client PC, this key serves to authenticate the PC to GCP (specifically to the project with which it was associated).

What if I want to BYOK ? (Bring my own key pair)

Yes – that is entirely possible. You are not constrained to use the key generated within Google Console. You can upload the public part of your key pair and associate it with a project just as easily as doing so within the console.

Summary

All cloud vendors expose the concept of a service account (a role in AWS terminology).  In GCP, service accounts are ubiquitous – and serve to authenticate in lieu of a username / password.  The service account (which is in the format of an email address) – has a p12 key file (which servers as an associated password). The key file itself is protected by a user chosen password – so that even if it gets into the wrong hands, the keyfile is meaningless without the keyfile password.

Using this combination, one can provide automated (computer to computer) access to cloud storage buckets, google drives and any API driven  resource in GCP (which is EVERY single resource in GCP). Happy Google Clouding!