- On the subject of encryption,
let's now talk about managing your own encryption keys.
So the options for bringing your own keys
are to have a customer-supplied encryption keys
or to do client-side encryption.
Let's talk about customer-supplied encryption keys.
This can only be used for Cloud Storage,
so it is not generally applicable for GCP services
but only for Cloud Storage.
You provide your own AES256 key,
encoded in standard Base64.
Cloud storage will use the key when encrypting
the object's data, the object's checksum
and the object's MD5 hash.
Cloud Storage uses standard server-side keys
to encrypt the remaining metadata.
One caveat is that you need
to supply the key in every request.
And note that you cannot use the console
to download objects encrypted with CSEK.
You would have to always use in this case the CLI
or do it programmatically from an application.
The general flow to use CSEK is to generate a Base64-encoded
AES256 encryption key.
Then to configure the client to use the key,
not the console once again,
and upload and get object using the client.
Then there is client-side encryption.
Client-side encryption is the encryption you perform
prior to sending any data that would be
within the application or the client.
You must create and manage your own encryption keys
in this case using your own tools.
You can use Google's open-source cryptographic SDK, Tink,
although again, you can use any tool that you prefer.
To use client-side encryption,
you generate a data encryption key locally.
Then you use the data encryption key to encrypt the message.
You can then use Cloud KMS to wrap the data encryption key
with the key encryption key and store the encrypted data
and the wrapped data encryption key.
Tink, that open-source product from Google I just mentioned,
would make this easy by abstracting all of these steps.