When running a workload inside a Confidential Container with remote attestation, you enhance the security of your workload in two key ways:
- The Confidential Container operates within a Trusted Execution Environment (TEE), ensuring no unauthorized party can access its memory.
- The Confidential Container runs a verified and trusted version of the code, providing assurance that the code has not been tampered with.
However, this is not enough when you are using a solution based on Confidential VMs, either on the cloud or on-premises, and that is because the disk of the Confidential VM introduces additional potential vulnerabilities. The next section further dives into these.
Potential vulnerabilities of the Confidential VM disk image
Malicious insiders or software running outside the Trusted Execution Environment can still access the disk image of the Confidential VM, potentially reading sensitive data or altering the application's behavior.
Scenario analysis: risks of Confidential VM disk exposure
A Confidential VM has a disk containing necessary binaries and configuration files, even for a stateless workload. During runtime, it may generate files (those could be temporary, or output files) on this disk. If these files contain sensitive data, a malicious insider with access to the disk image could read and retrieve this information.
You could try to identify and encrypt all files containing sensitive data or ensure they are only used in memory without being written to disk. However, this is often impractical: you might not own the application code, could misidentify sensitive files, and would need to repeat this effort with each new container version.
Scenario analysis: attestation quotes and disk access
An application inside a Confidential Container generates an attestation quote and shares it with a relying party to establish trust. The relying party then trusts the application. However, if a malicious insider or software gains access to the disk, they can modify the binaries or configuration files while the application is running, altering its behavior. Although the application's memory is protected by Confidential Computing technology, the disk is not.
When considering a solution for these issues, encrypting the Confidential Container disk is an option. However, using the Cloud Service Provider (CSP) disk encryption methods raises several concerns:
- Who has access to the encryption key? The CSP administrators, or personnel from your company? If the key is compromised, the encryption loses its effectiveness.
- Each CSP has a different way of configuring disk encryption, requiring repeated efforts for multi-cloud or hybrid deployments.
Anjuna Seaglass: comprehensive Confidential Computing protection
Anjuna Seaglass offers a solution to these challenges that is entirely transparent and independent of both the Cloud Service Provider (CSP) and Confidential Computing technology.
The Anjuna Confidential Runtime seamlessly encrypts the primary disk (OS disk) of the Confidential VM hosting the Confidential Container. This process is transparent to the application within the container and doesn’t necessitate any container modifications. The encryption encompasses the entire disk, eliminating the need to distinguish between sensitive and non-sensitive files.
Ephemeral encryption keys for enhanced security
The encryption key utilized for encrypting the disk is ephemeral; it is generated randomly when the Anjuna Confidential Container boots and is solely accessible to the container itself. No administrator can access this key. Consequently, even if the enclave is forcefully terminated and the disk remains, its contents remain unreadable since no one possesses the encryption key. Upon running the same Anjuna Confidential Container anew, it will employ an entirely new random key.
Integrity checks: preventing unauthorized disk modifications
Finally, the Anjuna Confidential Runtime also conducts integrity checks on the disk. If any malicious actor (human or software) attempts to alter the encrypted disk content, the Anjuna Confidential Runtime promptly detects such unauthorized changes and halts the operation of the Anjuna Confidential Container. This ensures that only modifications initiated by the Anjuna Confidential Container itself are trusted.
In summary, although running an application inside a Trusted Execution Environment protects the memory and CPU, another vector of attack remains for Confidential VMs - the OS disk of the TEE.
As always, Anjuna Seaglass offers a seamless solution to this issue, compatible with any Confidential Computing technology, across all Cloud Service Providers and on-premises setups.
If you want to take the next step, contact us or start free.
Try free for 30 days on AWS, Azure or Google Cloud, and experience the power of intrinsic cloud security.
Start Free