Customer-supplied encryption keys (CSEK) are a feature in
Google Cloud
Storage
and
Google Compute Engine
. If you supply your own
encryption keys, Google uses your key to protect the Google-generated keys used
to encrypt and decrypt your data.
Terms used in this topic
:
Data encryption key (DEK)
: A key used to encrypt data.
Key encryption key (KEK)
: A key used to encrypt, or "wrap", a data
encryption key.
Cluster Manager
: A collection of processes running under a Cluster
Manager identity in Google's production infrastructure. Implements the logic for
managing Compute Engine resources such as disks and VM instances. Stores
metadata relating to these resources.
Instance Manager
: A collection of processes running under an Instance
Manager identity in Google's production infrastructure. Executes modifications
to VM instances (processes) on the fleet such as VM start/stop or disk
attach/detach. Cluster Manager specifies what the state of the VMs should be at
any point in time, and Instance Manager works to execute on that.
How customer-supplied encryption keys work
The following provides information on how customer-supplied encryption keys work
with Google Cloud Storage and Google Compute Engine.
Cloud Storage
When you use customer-supplied encryption keys in
Cloud Storage
:
You provide a
raw CSEK
as part of an API call. This key is transmitted
from the Google front end to the storage system’s memory. This key is used as
the key encryption key in Google Cloud Storage for your data.
The raw CSEK is used to unwrap
wrapped chunk keys
, to create
raw chunk
keys
in memory. These are used to decrypt data chunks stored in the storage
systems. These keys are used as the data encryption keys (DEK) in Google Cloud
Storage for your data.
Key(s)
|
Stored in
|
Purpose
|
Accessible until
|
Raw CSEK
|
Storage system memory
|
Provided by the customer.
Key encryption key
(KEK) for chunk keys.
Wraps the chunk keys.
|
Customer-requested operation (e.g.,
insertObject
or
getObject
) is complete
|
Wrapped chunk keys
|
Storage devices
|
Protect chunk keys stored at rest
|
Storage object is deleted
|
Raw chunk keys
|
Storage devices’ memory
|
Data encryption key
(DEK) for the
data.
Read/write data to the disk.
|
Customer-requested operation is complete
|
Compute Engine
When you use customer-supplied encryption keys in
Compute Engine
:
You provide a
raw CSEK
as part of an API call.
This key is transmitted from the Google front end to the Cluster Manager’s
front end:
- If a wrapped CSEK was provided, then it is unwrapped using a
Google-owned asymmetric wrapping key
.
- The raw CSEK is combined with a per-persistent disk
cryptographic
nonce
to generate a
CSEK-derived key
. This key is used as the key
encryption key in Google Compute Engine for your data.
In the Cluster Manager front end, both the CSEK and the CSEK-derived key are
kept only in the Cluster Manager memory. The CSEK-derived key is used in the
Cluster Manager memory to unwrap the wrapped disk keys which are stored in the
Cluster Manager instance metadata and Instance Manager metadata, where automatic
restart is enabled (these are not the same as the
instance metadata
).
- The CSEK-derived key is used to wrap
raw disk keys
when creating a
disk, and to unwrap raw disk keys when accessing a disk.
- If automatic restart is enabled, the wrapped disk keys are persisted by
the Cluster Manager for the lifespan of the VM so that the VM can be
restarted in the event of a crash. The wrapped disk keys are wrapped with a
Google-owned symmetric wrapping key. The permissions of the wrapping key allow it to be used
only by Google Compute Engine. If automatic restart is turned off, the wrapped disk keys are deleted using the deletion process that is described in
Data deletion on Google Cloud
.
- If live migration is enabled, the raw disk key is passed from the old VM
instance memory to the new VM instance memory without the Instance Manager or
Cluster Manager being involved in the key copy.
Key(s)
|
Held by
|
Purpose
|
Accessible until
|
Raw CSEK
|
Cluster Manager front end
|
Provided by the customer.
Used to derive the CSEK-derived key by
adding a cryptographic nonce.
|
Customer-requested operation (e.g.,
instances.insert
,
instances.attachDisk
) is complete
|
Public-key wrapped CSEK
(Optional - where
RSA key
wrapping is used
)
|
Cluster Manager front end
|
Optionally provided by the customer.
Used to derive the CSEK-derived
key by first unwrapping with a Google-owned asymmetric key.
|
Customer-requested operation is complete
|
Asymmetric wrapping key
(where RSA key wrapping is used)
|
Google’s internal key management service
|
Used to unwrap an RSA-wrapped key provided by the customer
|
Indefinitely
|
CSEK-derived key
|
Cluster Manager front end
|
Key encryption key
(KEK) for disk keys.
Wraps the disk keys.
|
Key wrapping or unwrapping operation is complete
|
Google-wrapped disk keys
(Optional - where
automatic restart
is used)
|
Cluster Manager front end
|
Protect disk keys stored at rest, for disks attached to running
instances.
Restart the instance in cases where the VM memory is lost
(e.g., host crash)
|
VM is stopped or deleted
|
Raw Disk keys
|
Virtual Machine Monitor (VMM) memory,
Cluster Manager
(CM) memory
|
Data encryption key
(DEK) for the data.
Read/write data to the disk, live-migrate the VM, and perform in-place upgrades
|
VM is stopped or deleted
|
Google-wrapped CSEK-derived key
|
Cluster Manager database
|
Restart the operation in case of failure
|
Customer-requested operation is complete
|
How customer-supplied encryption keys are protected
The following provides information on how customer-supplied encryption keys are
protected on disk, as they move around the Google Cloud Platform infrastructure,
and in memory.
On disk
Raw CSEK
,
CSEK-derived keys
, and
raw chunk/disk keys
are never
stored on disk unencrypted. Raw chunk/disk keys are stored wrapped with
CSEK-derived keys, and with Google keys where automatic restart is used. Google
does not permanently store your keys on its servers.
As they move around the infrastructure
Each service uses access management features provided by the infrastructure to
specify exactly which other services can communicate with it. That service is
configured with the whitelist of the allowed service account identities, and
this access restriction is then automatically enforced by the infrastructure.
Learn more about
service identity, integrity, and isolation
.
Beyond the RPC authentication and authorization capabilities discussed in the
previous sections, the infrastructure also provides cryptographic privacy and
integrity for RPC data on the network. Services can configure the level of
cryptographic protection they want for each infrastructure RPC, and these are
enabled for customer-supplied encryption keys. Learn more about the
encryption of inter-service communications
.
In memory
Key material lives in various systems’ memory as detailed above, including
Cluster Manager memory and virtual machine monitor memory. Access to these
systems’ memory is by exception, e.g., as part of an incident, and managed by
access control lists. These systems either have memory dumps disabled, or
automatically scan for key material in memory dumps. Access to the jobs
themselves are restricted to a small number of Site Reliability Engineers as
needed as part of their role to maintain the service, and access to logs to a
small number of Software Engineers working on these features for debugging.
Learn more