Confidential Computing is the protection of data in-use with hardware-based Trusted Execution Environment (TEE). TEEs are secure and isolated environments that prevent unauthorized access or modification of applications and data while they are in use. This security standard is defined by the Confidential Computing Consortium.
End-to-end encryption is comprised of three states.
- Encryption-at-rest protects your data while it is being stored.
- Encryption-in-transit protects your data when it is moving between two points.
- Encryption-in-use protects your data while it is being processed.
Confidential Computing provides the last piece of end-to-end encryption: encryption-in-use.
A Confidential VM is a type of Compute Engine VM that ensures that your data and applications stay private and encrypted even while in use. You can use a Confidential VM as part of your security strategy so you do not expose sensitive data or workloads during processing.
Confidential VM runs on hosts with AMD EPYC processors which feature AMD Secure Encrypted Virtualization (SEV). Incorporating SEV into Confidential VM provides the following benefits and features.
Isolation: Encryption keys are generated by the AMD Secure Processor (SP) during VM creation and reside solely within the AMD System-On-Chip (SOC). These keys are not even accessible by Google, offering improved isolation.
High performance: AMD SEV offers high performance for demanding computational tasks. Enabling Confidential VM has little or no impact on most workloads, with only a 0-6% degradation in performance.
Enable Confidential VM
You can enable Confidential Computing whenever you create a new VM. Creating a Confidential VM only requires an extra checkbox or 1-2 more lines of code than creating a standard VM. You can continue using the other tools and workflows you're already familiar with. Adding Confidential Computing requires no changes to your existing applications.
Confidential Space is designed to let parties share sensitive data with a mutually agreed upon workload, while they retain confidentiality and ownership of that data. Such data might include personally identifiable information (PII), protected health information (PHI), intellectual property, cryptographic secrets, and more. Confidential Space helps create isolation so that data is only visible to the workload and the original owners of the data.
Confidential Space uses a TEE that is designed to release secrets only to authorized workloads. An attestation process and hardened OS image help protect the workload and the data that the workload processes from an untrusted operator.
A Confidential Space system has three core components:
- A workload: a containerized image run on top of the Confidential Space image, a hardened OS based on Container-Optimized OS. This runs on Confidential Computing, a cloud-based TEE that offers hardware isolation and remote attestation capabilities.
- An attestation service: an OpenID Connect (OIDC) token provider that verifies the attestations for the TEE and releases authentication tokens. The tokens contain identification attributes for the workload. The attestation service runs in the same region that the workload is running in.
- A protected resource: a managed cloud resource such as a Cloud Key Management Service (Cloud KMS) key or Cloud Storage bucket. The resource is protected by an allow policy that grants access to authorized federated identity tokens. An intermediate step, using workload identity pools, transforms the OIDC tokens to federated identity tokens that IAM can consume, providing certain conditions are met.
In a Confidential Space system, there are three role types:
- The workload author, who creates a containerized image that includes an application that has access to the protected resources. The author has no access to, and can't control access to the data or the results.
- The workload operator, who runs the workload in a Google Cloud project. The operator typically has full administrative privileges on the project. The operator can manage resources such as Compute Engine instances, disks, and networking rules, and can interact with any Google Cloud API that acts on them. The operator has no access to, and can't control access to the data or the results, and can't influence or modify the workload code or execution environment.
- The resource owners (or data collaborators), who own the protected resource. A resource owner can access their own data, set permissions on that data, and access the workload's results based on that data. They can't access the other resource owner's data, or modify the workload code by themselves.
Confidential Space supports a trust model where the workload author, workload operator, and resource owners are separate, mutually distrusting parties. The following diagram shows the system components and parties. The workload is located in a separate project from the protected resource.
There is no additional cost to use Confidential Space. You are only billed for the cost of the Confidential VM, and other resources you might use in the process like Cloud Storage.
For more detail about Confidential Space's use cases and how it works, see Confidential Space security overview.
Confidential Space requires Confidential Computing and Certificate Authority Service to work. These services are available in the locations detailed in the following links:
Other Confidential Computing services
Google Cloud also offers the following Confidential Computing services:
Confidential Google Kubernetes Engine Nodes enforce the use of Confidential VM for all of your GKE nodes.
Dataproc Confidential Compute features Dataproc clusters that use Confidential VMs.
Dataflow Confidential VM features Dataflow worker VMs that use Confidential VMs.
To quickly create a Confidential VM instance, try the quickstart.
For in-depth instructions about how to create a Confidential VM instance, see Creating a Confidential VM instance.