Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://cloud.google.com/compute/docs/disks/disk-encryption below:

About disk encryption | Compute Engine Documentation

Stay organized with collections Save and categorize content based on your preferences.

By default, Compute Engine encrypts customer content at rest. Compute Engine automatically uses Google-owned and Google-managed encryption keys to encrypt your data.

However, you can customize the encryption Compute Engine uses for your resources by providing key encryption keys (KEKs). Key encryption keys don't directly encrypt your data, but encrypt the Google-owned and managed keys that Compute Engine uses to encrypt your data.

You have two options to provide key encryption keys:

• Recommended. Use customer-managed encryption keys (CMEKs) in Cloud KMS with Compute Engine. Using Cloud KMS keys gives you control over their protection level, location, rotation schedule, usage and access permissions, and cryptographic boundaries. Using Cloud KMS also lets you track key usage, view audit logs, and control key life cycles. Instead of Google owning and managing the symmetric key encryption keys (KEKs) that protect your data, you control and manage these keys in Cloud KMS.

  You can create CMEKs manually, or you can use Cloud KMS Autokey to have them created automatically on your behalf.

  In most cases, after you create a CMEK-encrypted disk, you don't need to specify the key when working with the disk.

• You can manage your own key encryption keys outside of Compute Engine, and provide the key whenever you create or manage a disk. This option is known as customer-supplied encryption keys (CSEKs). When you manage CSEK-encrypted resources, you must always specify the key you used when encrypting the resource.

For more information about each encryption type, see Customer-managed encryption keys and Customer-supplied encryption keys.

To add an additional layer of security to your Hyperdisk Balanced disks, enable Confidential mode. Confidential mode adds hardware-based encryption to your Hyperdisk Balanced disks.

This section lists the supported encryption types for disks and other storage options offered by Compute Engine.

• Persistent Disk volumes support Google-owned and managed keys, CMEKs and CSEKs.

• Google Cloud Hyperdisk support CMEKs and Google-owned and managed keys. You can't use CSEKs to encrypt Hyperdisks.

• Local SSD disks only support Google-owned and managed keys. You can't use CSEKs or CMEKs to encrypt Local SSD disks.

• Disk clones and machine images support Google-owned and managed keys,CMEKs, and CSEKs.

• Standard snapshots and instant snapshots support Google-owned and managed keys, CMEKs, and CSEKs.

Compute Engine rotates the Google-owned and managed keys used to protect your data on a yearly basis. Key rotation is an industry best practice for data security that limits the potential impact of a compromised key.

If you use CMEKs, Google recommends that you enable automatic rotation for your disks. For more information, see Rotate your Cloud KMS encryption key for a disk.

If you choose to use Cloud KMS keys to protect your Compute Engine resources, you can either create CMEKs manually or use Cloud KMS Autokey to create the keys. With Autokey, key rings and keys are generated on demand as part of resource creation in Compute Engine. Service agents that use the keys for encrypt and decrypt operations are created if they don't already exist and are granted the required Identity and Access Management (IAM) roles. For more information, see Autokey overview.

To learn how to use CMEKs created by Cloud KMS Autokey to protect your Compute Engine resources, see Using Autokey with Compute Engine resources.

When using Autokey to create keys to protect your Compute Engine resources, Autokey doesn't create new keys for snapshots. You must encrypt a snapshot with the same key used to encrypt the source disk. If you create a snapshot using the Google Cloud console, the encryption key used by the disk is automatically applied to the snapshot. If you create a snapshot using the gcloud CLI, Terraform, or the Compute Engine API, you must get the resource identifier of the key used to encrypt the disk and then use that key to encrypt the snapshot.

For more information about how to use manually-created customer-managed encryption keys (CMEK) to encrypt disks and other Compute Engine resources, see Protect resources by using Cloud KMS keys.

To learn how to use customer-supplied encryption keys (CSEK) to encrypt disks and other Compute Engine resources, see Encrypting disks with customer-supplied encryption keys.

Disks in Compute Engine are encrypted with one of the following types of encryption keys:

• Google-owned and managed keys
• Customer-managed encryption keys (CMEKs)
• Customer-supplied encryption keys (CSEKs)

By default, Compute Engine uses Google-owned and managed keys.

To view a disk's encryption type, you can use the gcloud CLI, Google Cloud console, or the Compute Engine API.

1. In the Google Cloud console, go to the Disks page.

   Go to Disks

2. In the Name column, click the name of the disk.

3. In the Properties table, the row labeled Encryption indicates the type of encryption: Google managed, Customer-managed, or Customer-supplied.

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Use the gcloud compute disks describe command:

       gcloud compute disks describe DISK_NAME \
         --zone=ZONE \
         --format="json(diskEncryptionKey)"
     

   Replace the following:

   • PROJECT_ID: your project ID.
   • ZONE: the zone where your disk is located.

   • DISK_NAME: the name of the disk.

     Command output

     If the output is null, the disk uses a Google-owned and managed key.

     Otherwise, the output is a JSON object.

     If the JSON object contains a field named diskEncryptionKey, the disk is encrypted. The diskEncryptionKey object contains information about whether the disk is CMEK- or CSEK-encrypted:

     • If the diskEncryptionKey.kmsKeyName property is present, the disk is CMEK-encrypted. The kmsKeyName property indicates the name of the specific key used to encrypt the disk:

       {
         "diskEncryptionKey": {
           "kmsKeyName": "projects/my-proj/.."
         }
       }
       

     • If the diskEncryptionKey.sha256 property is present, the disk is CSEK-encrypted. The sha256 property is the SHA-256 hash of the customer-supplied encryption key that protects the disk.

         {
           "diskEncryptionKey": {
             "sha256": "abcdefghijk134560459345dssfd"
           }
         }
           

Make a POST request to the compute.disks.get method.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/disks/DISK_NAME

Replace the following:

• PROJECT_ID: your project ID.
• ZONE: the zone where your disk is located.
• DISK_NAME: the name of the disk

Request response

If the response is null, the disk uses a Google-owned and managed key.

Otherwise, the response is a JSON object.

If the JSON object contains a field named diskEncryptionKey, the disk is encrypted. The diskEncryptionKey object contains information about whether the disk is CMEK- or CSEK-encrypted:

• If the diskEncryptionKey.kmsKeyName property is present, the disk is CMEK-encrypted. The kmsKeyName property indicates the name of the specific key used to encrypt the disk:

  {
    "diskEncryptionKey": {
      "kmsKeyName": "projects/my-proj/.."
    }
  }
  

• If the diskEncryptionKey.sha256 property is present, the disk is CSEK-encrypted. The sha256 property is the SHA-256 hash of the customer-supplied encryption key that protects the disk.

    {
      "diskEncryptionKey": {
        "sha256": "abcdefghijk134560459345dssfd"
      }
    }
      

If the disk uses CMEKs, you can find detailed information about the key, its key ring and location by following the steps in View keys by project.

If the disk uses CSEKs, contact your organization's administrator for details about the key. Using CMEK, you can also see what resources that key protects with key usage tracking. For more information, see View key usage.

If you use Confidential Computing, you can extend the hardware-based encryption to your Hyperdisk Balanced volumes by enabling Confidential mode.

Confidential mode for your Hyperdisk Balanced volumes lets you enable additional security without having to refactor the application. Confidential mode is a property that you can specify when you create a new Hyperdisk Balanced volume.

Hyperdisk Balanced volumes in Confidential mode can only be used with Confidential VMs.

To create a Hyperdisk Balanced volume in Confidential mode, follow the steps in Create a Hyperdisk Balanced volume in Confidential mode.

Hyperdisk Balanced volumes in Confidential mode can only be used with Confidential VMs that use the N2D machine type.

Confidential mode for Hyperdisk Balanced volumes is available in the following regions:

• europe-west4
• us-central1
• us-east4
• us-east5
• us-south1
• us-west4

• Hyperdisk Extreme, Hyperdisk Throughput, Hyperdisk ML, and Hyperdisk Balanced High Availability don't support Confidential mode.
• You can't suspend or resume a VM that uses Hyperdisk Balanced volumes in Confidential mode.
• You can't use Hyperdisk Storage Pools with Hyperdisk Balanced volumes in Confidential mode.
• You can't create a machine image or a custom image from a Hyperdisk Balanced volume in Confidential mode.

• To learn how to automate the creation of CMEKs, see Cloud KMS with Autokey (Preview).
• To learn how to create CMEKs, see Create encryption keys with Cloud KMS.
• Encrypt a disk with customer-managed encryption keys (CMEKs).
• To create a Hyperdisk Balanced volume in Confidential mode, see Create a Hyperdisk Balanced volume in Confidential mode.
• Learn more about the format and specification for CSEKs.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-07 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["Compute Engine encrypts data at rest by default using Google-owned and managed keys, but offers options for customer-managed encryption."],["Customers can manage their own encryption keys through two methods: Customer-Managed Encryption Keys (CMEKs) via Cloud KMS, which offers greater control, or Customer-Supplied Encryption Keys (CSEKs), where they manage keys outside of Compute Engine."],["Cloud KMS Autokey can automatically create and manage CMEKs during resource creation, simplifying key management for Compute Engine resources."],["Hyperdisk Balanced volumes can be used with Confidential mode, adding hardware-based encryption, but this is limited to specific machine types and regions."],["Disks can have their encryption type identified through the gcloud CLI, Google Cloud Console, or Compute Engine API to determine whether they are using Google-managed, CMEK, or CSEK encryption."]]],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4