Stay organized with collections
Save and categorize content based on your preferences.
This page describes best practices for securing your
Google Distributed Cloud Edge installation.
Physical hardware security
You are responsible for the physical security of the
Distributed Cloud Edge rack, such as limiting access to
authorized personnel. The Distributed Cloud Edge
rack itself has the following security features:
Access to the hardware installed on the rack is possible only through the
front and back rack doors.
The rack cannot be easily disassembled. There are no externally accessible
structural fasteners such as screws, nuts, latches, or rivets.
The rack doors are equipped with key locks. Google supplies you with a copy
of the key and retains a copy for safe keeping.
For multi-rack installations, all rack locks are keyed identically.
The rack doors have perforated tamper-proof metal mesh for ventilation.
During installation, the rack is securely bolted to the installation site
floor by using its shipping braces and brackets.
If you have further questions about the security of the physical rack, contact
your Google Cloud sales representative.
Local storage security
Distributed Cloud Edge uses Linux Unified Key Setup (LUKS) to
encrypt the logical volumes on each Distributed Cloud Edge node.
You have the option to use customer-managed encryption keys (CMEK) or
Google-owned and managed keys to wrap the LUKS disk encryption key (DEK). When you assign
a node to a node pool, the node generates a LUKS DEK and wraps it in either a
Google-managed LUKS passphrase, also known as the key encryption
key (KEK), or one provided by you through Cloud KMS. You can choose
whether to use Cloud KMS when creating a node pool.
Distributed Cloud Edge integrates with
Cloud KMS by using the
envelope encryption model.
Additionally, each Distributed Cloud Edge machine does the
following on every cold start:
If you are not using Cloud KMS, the machine generates a new KEK
(LUKS passphrase) and sets up encrypted storage from the beginning.
If you are using Cloud KMS, the machine fetches the KEK from
Cloud KMS and unlocks the existing logical volumes that hold your
data.
Enable support for customer-managed encryption keys (CMEK) for local storage
To enable Cloud KMS integration with
Distributed Cloud Edge, complete the following steps:
Create a keyring, a symmetric key, and one or more key versions to use with
Distributed Cloud Edge. You must create these artifacts in the
same Google Cloud region as your Distributed Cloud Edge
installation. For instructions, see Create a key.
Grant the Cloud KMS CryptoKey Encrypter/Decrypter role
(roles/cloudkms.cryptoKeyEncrypterDecrypter) to the
Distributed Cloud Edge Service Account in your
Google Cloud project. You must do this for each key version that you want
to use with Distributed Cloud Edge. If you revoke this role
after you integrate your Distributed Cloud Edge
installation with Cloud KMS, you lose access to data
stored on the Distributed Cloud Edge machines.
Create a node pool
by using the --local-disk-kms-key flag, and provide the
full path to the key version that you want to use with that node pool.
Create a cluster
by using the --control-plane-kms-key flag, and provide the
full path to the key version that you want to use with the node running
the cluster's control plane.
You are responsible for maintaining functioning redundant backups of all the
data that you choose to store on Distributed Cloud Edge
hardware and exporting that data when you choose to return
Distributed Cloud Edge hardware to Google.
Any data still present on the Distributed Cloud Edge hardware
when it is returned to Google is wiped. If a failure of
Distributed Cloud Edge hardware occurs and Google performs
on-site repairs, all storage media is removed from the
Distributed Cloud Edge machine being serviced and is placed into
your custody for the duration of the repair.
Network security
Your business requirements and your organization's network security policy
dictate the steps necessary to secure network traffic that flows in and out of
your Distributed Cloud Edge installation. In addition, we
recommend the following:
Allow only inbound connections to virtual IP address pools exposed
by the Distributed Cloud Edge built-in load balancer and to
Distributed Cloud Edge subnetworks.
Disallow inbound connections from external network resources to IP addresses of
local control plane endpoints. For more information, see
Survivability mode.
For more information about how to prepare your local network for connecting
Distributed Cloud Edge hardware, see
Networking.
[[["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-09-04 UTC."],[[["\u003cp\u003ePhysical security of the Distributed Cloud Edge rack is the customer's responsibility, with features like locked doors and secure bolting provided by the hardware.\u003c/p\u003e\n"],["\u003cp\u003eLocal storage encryption on Distributed Cloud Edge uses LUKS, and customers can choose between using Google-managed keys or customer-managed encryption keys (CMEK) via Cloud KMS for enhanced security.\u003c/p\u003e\n"],["\u003cp\u003eTo use CMEK for local storage, customers must create a keyring and key, grant the Cloud KMS CryptoKey Encrypter/Decrypter role to the Distributed Cloud Edge service account, and specify the key when creating a node pool and cluster.\u003c/p\u003e\n"],["\u003cp\u003eCustomers are responsible for backing up their data stored on Distributed Cloud Edge hardware and must export it before returning the hardware to Google, as any remaining data will be wiped.\u003c/p\u003e\n"],["\u003cp\u003eSecuring network traffic for Distributed Cloud Edge is based on the customer's network security policy, but it is recommended to limit inbound connections and disallow external connections to system and service management layers, as well as to local control plane endpoints.\u003c/p\u003e\n"]]],[],null,["# Security best practices\n\nThis page describes best practices for securing your\nGoogle Distributed Cloud Edge installation.\n\nPhysical hardware security\n--------------------------\n\nYou are responsible for the physical security of the\nDistributed Cloud Edge rack, such as limiting access to\nauthorized personnel. The Distributed Cloud Edge\nrack itself has the following security features:\n\n- Access to the hardware installed on the rack is possible only through the front and back rack doors.\n- The rack cannot be easily disassembled. There are no externally accessible structural fasteners such as screws, nuts, latches, or rivets.\n- The rack doors are equipped with key locks. Google supplies you with a copy of the key and retains a copy for safe keeping.\n- For multi-rack installations, all rack locks are keyed identically.\n- The rack doors have perforated tamper-proof metal mesh for ventilation.\n- During installation, the rack is securely bolted to the installation site floor by using its shipping braces and brackets.\n\nIf you have further questions about the security of the physical rack, contact\nyour Google Cloud sales representative.\n\nLocal storage security\n----------------------\n\nDistributed Cloud Edge uses Linux Unified Key Setup (LUKS) to\nencrypt the logical volumes on each Distributed Cloud Edge node.\nYou have the option to use customer-managed encryption keys (CMEK) or\nGoogle-owned and managed keys to wrap the LUKS disk encryption key (DEK). When you assign\na node to a node pool, the node generates a LUKS DEK and wraps it in either a\nGoogle-managed LUKS passphrase, also known as the key encryption\nkey (KEK), or one provided by you through Cloud KMS. You can choose\nwhether to use Cloud KMS when creating a node pool.\nDistributed Cloud Edge integrates with\nCloud KMS by using the\n[envelope encryption model](/kms/docs/envelope-encryption).\n\nAdditionally, each Distributed Cloud Edge machine does the\nfollowing on every cold start:\n\n- If you are not using Cloud KMS, the machine generates a new KEK\n (LUKS passphrase) and sets up encrypted storage from the beginning.\n\n- If you are using Cloud KMS, the machine fetches the KEK from\n Cloud KMS and unlocks the existing logical volumes that hold your\n data.\n\n### Enable support for customer-managed encryption keys (CMEK) for local storage\n\nTo enable Cloud KMS integration with\nDistributed Cloud Edge, complete the following steps:\n\n1. Create a keyring, a symmetric key, and one or more key versions to use with\n Distributed Cloud Edge. You must create these artifacts in the\n same Google Cloud region as your Distributed Cloud Edge\n installation. For instructions, see [Create a key](/kms/docs/create-key).\n\n2. Grant the [Cloud KMS CryptoKey Encrypter/Decrypter role](/iam/docs/understanding-roles#cloud-kms-roles)\n (`roles/cloudkms.cryptoKeyEncrypterDecrypter`) to the\n Distributed Cloud Edge Service Account in your\n Google Cloud project. You must do this for each key version that you want\n to use with Distributed Cloud Edge. If you revoke this role\n after you integrate your Distributed Cloud Edge\n installation with Cloud KMS, *you lose access to data\n stored on the Distributed Cloud Edge machines.*\n\n3. [Create a node pool](/distributed-cloud/edge/1.5.1/docs/nodepools#create)\n by using the `--local-disk-kms-key` flag, and provide the\n full path to the key version that you want to use with that node pool.\n\n4. [Create a cluster](/distributed-cloud/edge/1.5.1/docs/clusters#create)\n by using the `--control-plane-kms-key` flag, and provide the\n full path to the key version that you want to use with the node running\n the cluster's control plane.\n\nFor more information, see\n[Customer-managed encryption keys (CMEK)](/kms/docs/cmek) in the\nCloud KMS documentation.\n\n### Data recovery and backups\n\nYou are responsible for maintaining functioning redundant backups of all the\ndata that you choose to store on Distributed Cloud Edge\nhardware and exporting that data when you choose to return\nDistributed Cloud Edge hardware to Google.\n\nAny data still present on the Distributed Cloud Edge hardware\nwhen it is returned to Google is wiped. If a failure of\nDistributed Cloud Edge hardware occurs and Google performs\non-site repairs, all storage media is removed from the\nDistributed Cloud Edge machine being serviced and is placed into\nyour custody for the duration of the repair.\n\nNetwork security\n----------------\n\nYour business requirements and your organization's network security policy\ndictate the steps necessary to secure network traffic that flows in and out of\nyour Distributed Cloud Edge installation. In addition, we\nrecommend the following:\n\n- Allow only inbound connections to virtual IP address pools exposed\n by the Distributed Cloud Edge built-in load balancer and to\n Distributed Cloud Edge subnetworks.\n\n- Disallow inbound connections from external network resources to subnetworks\n that serve the\n [system management](/distributed-cloud/edge/1.5.1/docs/how-it-works#network-layers)\n and [service management](/distributed-cloud/edge/1.5.1/docs/how-it-works#network-layers)\n layers.\n\n- Disallow inbound connections from external network resources to IP addresses of\n local control plane endpoints. For more information, see\n [Survivability mode](/distributed-cloud/edge/1.5.1/docs/survivability).\n\nFor more information about how to prepare your local network for connecting\nDistributed Cloud Edge hardware, see\n[Networking](/distributed-cloud/edge/1.5.1/docs/requirements#networking).\n\nWhat's next\n-----------\n\n- [Ensure high availability for your Distributed Cloud Edge installation](/distributed-cloud/edge/1.5.1/docs/availability)"]]
