What is confidential compute

note

Not every Codesphere instance offers confidential compute. Ask your Codesphere administrator whether confidential compute is available on your instance. See Prerequisites.

Confidential compute protects your services while they run, even from the people and systems that operate the infrastructure underneath. In Codesphere, landscape services and managed services can run in confidential mode. This page explains the trust model behind confidential compute and when it makes sense to use it.

The problem: trusting the operator

Encryption usually protects data in two states. Data at rest is encrypted on disk. Data in transit is encrypted with TLS. Data in use is not protected. To process data, an application has to load it into memory in plain text.

Anyone with privileged access to the host can read that memory. This includes:

• The cloud or hosting provider
• Data center staff with physical access
• Administrators of the hypervisor or the platform
• An attacker who has compromised any of the above

In a regular setup you have to trust all of them. Contracts, audits and certifications lower the risk, but they do not remove it on a technical level.

Shifting trust to the hardware manufacturer

Confidential compute relies on CPU features called trusted execution environments (TEEs), such as AMD SEV-SNP and Intel TDX. They provide two guarantees.

• Encrypted memory. The CPU encrypts the memory of a protected environment with keys that are generated inside the processor and never leave it. The host only ever sees ciphertext.
• Verifiable integrity. At startup, the CPU measures the software loaded into the protected environment. It signs this measurement with a key that is rooted in the hardware manufacturer. A remote party can check the signature against the manufacturer's public certificates and confirm exactly what is running.

As a result, you no longer need to trust the operator. You trust the hardware manufacturer to have built the CPU correctly, and you trust the software you chose to run. The operator still runs the hardware, but cannot look inside your service or change it without being detected.

Corresponding accessible text description

	Regular service	Confidential service
Who can read memory	Anyone with host access	Only the service itself
Who you trust	Operator, admins, hardware manufacturer	Hardware manufacturer and your own software
How integrity is checked	Not at all, or by process	Cryptographically, at every start

What is protected

Codesphere combines several mechanisms to protect data in every state.

What	How	Details
Data in use	Services run in encrypted micro-VMs	Confidential micro-VMs
Service integrity	Remote attestation against a trustee service	Attestation and the trustee service
Data in transit	Mutual TLS through a service mesh	Service mesh
Data at rest	LUKS volume encryption inside the VM	Encryption at rest

What is not protected

Confidential compute closes one specific gap. It is not a general security solution. Keep these limits in mind:

• Your own code. A vulnerability in your application or its dependencies still lets an attacker in. Once inside, the attacker runs within the trusted environment.
• Software you approve. Attestation confirms that the software you approved is running. If that software contains a backdoor, attestation confirms the backdoor too. See Recommendations for production.
• Availability. The operator can still stop, pause or delete services and limit their resources. Confidential compute protects confidentiality and integrity, not uptime.
• Metadata. The operator still sees resource usage, timing, the volume and endpoints of network traffic, and the size of stored data.

Where this is relevant

Confidential compute is worth the extra effort when the operator of your infrastructure is a risk you cannot accept. Typical cases:

• Regulated data. Health, financial or personal data where regulation or policy requires technical protection against operator access.
• Data sovereignty. You run on infrastructure in another jurisdiction or from another provider, but keep technical control over your data.
• Third-party hardware. You run on hardware you do not own, such as public cloud, colocation or partner data centers, and want the same guarantees everywhere.
• Intellectual property. You protect proprietary models, algorithms or training data from anyone with access to the host.

Next steps

• Check what your instance needs in Prerequisites.
• Learn how services are protected in use, in transit and at rest in Confidential architecture.
• See how service integrity is verified in Attestation and the trustee service.