Migrating encrypted SQL server(PaaS cloud SQL) data from one cloud project to another cloud project

Google Cloud Database
1

We have a Cloud SQL Server database in google cloud project A in landing zone L1.

We are moving to another landing zone L2 where the google cloud project is B.

Now some of the data in this database gets encrypted in server side code before getting saved to the sql server database. We now have to migrate this data to new SQL server instance of project B, the data is encrypted so if someone tries to access it we need the same keys(key management key ring(symmetric)) of project A to decrypt it.

Is there a way to migrate these Symmetric keys from Project A to project B so that the decryption do not fail?

Note: Project A of Landing zone L1 will be decommissioned/destroyed after we move to project B of Landing zone L2.

2

Migrating symmetric encryption keys in Google Cloud KMS when transitioning a Cloud SQL database from one project to another presents challenges due to strict security policies that prevent key material export. Because symmetric key material cannot be extracted, a direct migration is impossible. Instead, the process requires creating a new functionally equivalent key in the destination project and securely re-encrypting data.

When moving a Cloud SQL database from Project A to Project B, where Project A is set for decommissioning, the first step is to identify the key properties in Project A. Using the gcloud CLI, the key’s algorithm, protection level (software or HSM), and location should be noted to ensure an identical key can be created in Project B.

gcloud kms keys list --location=<location> --keyring=<keyring-name-A> --project=<project-A-id>

Once the key details are confirmed, a new keyring and symmetric key must be generated in Project B with identical attributes.

# Create the keyring (if it doesn't exist)
gcloud kms keyrings create <keyring-name-B> \
    --location=<location> \
    --project=<project-B-id>

# Create a new symmetric key
gcloud kms keys create <key-name-B> \
  --location=<location> \
  --keyring=<keyring-name-B> \
  --project=<project-B-id> \
  --purpose=encryption \
  --default-algorithm=GOOGLE_SYMMETRIC_ENCRYPTION \
  --protection-level=software  # or HSM if the original key was HSM

After creating the new key, application configurations must be updated to reference the new key’s resource ID in Project B. The most secure approach is to decrypt existing data using Project A’s key and immediately re-encrypt it using Project B’s key before storing it in the new database. This ensures data remains secure and eliminates dependency on Project A.

In scenarios where immediate re-encryption is not feasible, a temporary solution is to grant Project B’s service account decryption access to Project A’s KMS key, specifically the roles/cloudkms.cryptoKeyDecrypter role. This allows Project B to continue decrypting data with the original key until full migration is complete. However, this approach should be used cautiously, ensuring that Project A’s permissions are revoked as soon as possible after data is re-encrypted with the new key.

gcloud kms keys add-iam-policy-binding <key-name-A> \
    --location=<location> \
    --keyring=<keyring-name-A> \
    --project=<project-A-id> \
    --member="serviceAccount:<service-account-of-project-B>" \
    --role="roles/cloudkms.cryptoKeyDecrypter"

To enhance security and maintain compliance, it is advisable to enable key rotation on the new key in Project B and configure Cloud KMS audit logs for monitoring.

gcloud kms keys update <key-name-B> \
    --location=<location> \
    --keyring=<keyring-name-B> \
    --project=<project-B-id> \
    --rotation-period=90d  # Adjust rotation period as needed

Before decommissioning Project A, thorough testing should be conducted to confirm that applications can decrypt data using the new key without disruption.

Ultimately, while symmetric key migration is not directly possible, recreating an identical key and securely re-encrypting data ensures a seamless transition without compromising security. By following best practices such as least privilege access, thorough testing, and structured key rotation, organizations can execute a smooth migration while maintaining data integrity and security.

3

You have a database in Google Cloud Project A and you’re moving to Project B. Some of your data is encrypted, and you want to make sure you can still decrypt it after the move using the same keys.

Here’s how you can do it:

  1. Export the Keys: You can’t directly export keys from Google Cloud KMS, but you can encrypt your data using the keys and then decrypt it locally. You can export the key data using the Cloud KMS API or gcloud command-line tool.

  2. Import the Keys into Project B: Once you have the key data, you can import it into Project B’s Cloud KMS. This way, you can use the same keys to decrypt your data in the new project.

  3. Set Up Permissions: Make sure you have the right permissions to manage the keys in both projects. You’ll need roles like Cloud KMS CryptoKey Encrypter/Decrypter to handle encryption and decryption.

  4. Decommission Project A: After you’ve successfully moved and tested everything in Project B, you can shut down Project A.

4

You have a database in Google Cloud Project A and you’re moving to Project B. Some of your data is encrypted, and you want to make sure you can still decrypt it after the move using the same keys.

Here’s how you can do it:

Export the Keys: You can’t directly export keys from Google Cloud KMS, but you can encrypt your data using the keys and then decrypt it locally. You can export the key data using the Cloud KMS API or gcloud command-line tool.

Import the Keys into Project B: Once you have the key data, you can import it into Project B’s Cloud KMS. This way, you can use the same keys to decrypt your data in the new project.

Set Up Permissions: Make sure you have the right permissions to manage the keys in both projects. You’ll need roles like Cloud KMS CryptoKey Encrypter/Decrypter to handle encryption and decryption.

Decommission Project A: After you’ve successfully moved and tested everything in Project B