Hacker News new | past | comments | ask | show | jobs | submit | m1ghtym0's comments login

An alternative to using own servers, which are not feasible for every company would be isolated and encrypted GitLab/GitHub deployments as described here: https://dev.to/flxflx/setting-up-a-confidential-gitlab-333h


Maybe they should deploy it via Constellation https://github.com/edgelesssys/constellation


Who are "they"? Microsoft?

The issue is not a technological one but a matter of legislation.


Yes and no. It's a technological problem in the sense that there is a technological solution to this. See the Delos Cloud for example: https://www.handelsblatt.com/technik/it-internet/delos-cloud...

However Confidential Computing and Constellation unlock another technological solution where one can run IT infrastructure while being completely locked out and without access to the any of the data. Ensuring data sovereignty for the users and without building physically separated data centers.


Ohai, who should deploy what via Constellation? :)


What's your favorite take-away?


I hear that argument a lot. The key aspect here is remote attestation. Often enough CC is only seen from a memory encryption angle. It's maybe not straight forward, however remote attestation and of course the verifiability of such attestation claims are what makes CC unique.

The remote attestation capabilities of CC hardware allow to establish a secure channel from the hardware to the user, taking the CSP fully out of the equation. That applies even though the CSP implements the IaaS in between.

There is documentation that explains this in more detail if that's of interest to anyone following these discussions: * https://confidentialcomputing.io/wp-content/uploads/sites/85... * https://content.edgeless.systems/hubfs/Confidential%20Comput...


You are correct, KMS implement important aspects of key management. The conclusion of the article is not replacing KMS with Confidential Computing. Instead, the idea is to combine them to achieve the ultimate goal of protecting sensitive data. CC does not solve the who manages the KEK problem, it solves the using the DEK securely, accessing the KEK securely, and eventually, effectively protecting the processed data question.


The thing you're looking for is called remote attestation. That means there is a direct channel from the hardware to the user that attests the confidentiality and integrity of the VM. Such attestation statement is signed by a key burned into the CPU at production time. The remaining attack vector is leaking that key from the hardware itself. There is academic research on this topic. In essence, while technically possible, it is considered not practical, especially not at scale.


BYOK was a lie because it was only protecting keys at rest. When the environment in use becomes accessible to so many actors, customers lose control of their keys and identities once they are accessible to that hostile environment. “Bring your own key — share it with everyone.”

Confidential Computing fundamentally changes this by providing protection for keys in use and enabling trusted and verifiable runtime environments.

Solutions such as Constellation solve the shortcomings of BYOK using Confidential Computing so you can finally “Bring your own key — keep it yours”.


Applying Kata for TEEs and bringing Confidential Computing to Kubernetes is an awesome concept. I'm less sold on the original reverse idea of using VMs instead of containers for enhanced host security in cloud-native deployments. Though the big question is when will we see Kata support in the hyperscalers?


A deep dive into how Hashicorp, Confluent, Databricks, and CockroachDB grew their communities in the early days.


From a security perspective, Constellation is designed to keep all data always encrypted and to prevent any access from the underlying (cloud) infrastructure. This includes access from datacenter employees, privileged cloud admins, and attackers coming through the infrastructure. Such attackers could be malicious co-tenants escalating their privileges or hackers who managed to compromise a cloud server.


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: