As an additional layer on top of Google-managed encryption keys, you can choose to use keys generated by Cloud Key Management Service. Such keys are known as customer-managed encryption keys. If you use a customer-managed encryption key, your encryption keys are stored within Cloud KMS. The project that holds your encryption keys can then be independent from the project that contains your buckets, thus allowing for better separation of duties.
When is the key used?
When you apply a customer-managed encryption key to an object, Cloud Storage uses the key when encrypting:
- The object's data.
- The object's CRC32C checksum.
- The object's MD5 hash.
Cloud Storage uses standard server-side keys to encrypt the remaining metadata for the object, including the object's name. Thus, if you have sufficient permission, you can perform actions such as reading most metadata, listing objects, and deleting objects even after you've disabled or destroyed the associated customer-managed encryption key.
Encryption and decryption with customer-managed encryption keys is accomplished using service accounts. Once you give your Cloud Storage service account access to an encryption key, that service account encrypts:
- Objects added to a bucket that uses the key as the default key.
- Specific objects that you indicate should be encrypted with that key.
When adding or rewriting an object in Cloud Storage, if you have both a default key set on your bucket and a specific key included in your request, Cloud Storage uses the specific key to encrypt the object.
When a requester wants to read an object encrypted with a customer-managed encryption key, they simply access the object as they normally would. During such a request, the service account automatically decrypts the requested object as long as:
- The service account still has permission to decrypt using the key.
- You have not disabled or destroyed the key.
If one of these conditions is not met, the service account does not decrypt the data, and the request fails.
A Cloud KMS key resource has the following format:
[PROJECT_STORING_KEYS]is the ID of the project associated with the key. For example,
[LOCATION]is the key location. For example,
[KEY_RING_NAME]is the name of the key ring. For example,
[KEY_NAME]is the name of the key. For example,
The following restrictions apply when using customer-managed encryption keys:
You cannot use the JSON API Compose Object method when one or more of the source objects are encrypted with a customer-managed encryption key.
You cannot encrypt an object with a customer-managed encryption key by updating the object's metadata. Include the key as part of a rewrite of the object instead.
You must create the Cloud KMS key in the same location as the data you intend to encrypt. For example, if your bucket is located in
US-EAST1, any Cloud KMS key encrypting objects in that bucket must also be created in
US-EAST1. For available Cloud KMS locations, see Cloud KMS locations.
You cannot specify a customer-managed encryption key as part of a Storage Transfer Service transfer, and any such keys on source objects are not applied to the transferred objects. Set a default customer-managed key on your bucket prior to performing the transfer.
Relation to customer-supplied encryption keys
In addition to customer-managed encryption, Cloud Storage offers Customer-Supplied Encryption Keys as a way of controlling your data encryption. You can encrypt different objects in a single bucket with different encryption methods, but note that:
A single object can only be encrypted by one of these methods at a time.
If you have a default customer-managed key set for your bucket and specify a customer-supplied key in a request, Cloud Storage uses the customer-supplied key to encrypt the object.
You can set a default customer-managed key on your bucket, but you cannot set a default customer-supplied key on your bucket.