demos: Gramine-SGX and Pytorch

[magowan]

The demo is great to see and certainly relates to confidential computing and cloud native.

My concern is that I expect documentation of demos here to be directly related to the repos within the project of confidential containers? I am not sure we have really aligned gramine with the projects here just yet so it kind of feels like a demo of gramine not of the activities currently happening within the confidential containers project?

For me a link to gramine project as other confidential computing projects (relationship to be explored) may be something to consider but I am not sure a full set of documentation to demo make sense at this time. When we align better and there is more commonality between gramine and confidential containers efforts then I am all for adding something like this. Happy to perhaps discuss further on Thursday and figure out how we work to align?

[mythi]

Happy to perhaps discuss further on Thursday and figure out how we work to align?

We had already reached the alignment that Gramene-style confidential containers workloads fit into the project scope (in one of the weekly calls late Oct). I guess the only open is where to maintain this demo so that this project links to it correctly.

I will join the call on Thu for the second half (I have a conflict for the first 30minutes).

[dcmiddle]

Yeah we can definitely talk about it in the community call. Also, here's some thoughts for this thread... Container isolation scope is here: https://github.com/confidential-containers/documentation/pull/5 Previous discussions also talked about this project being a sort of integration across external components. I think if this was simply linking to a single external project it might not be interesting. In this case, this PR shows how to integrate Gramine, Kata, and Pytorch. Would it be even more interesting if it connected to other components? Probably. But this is also part of the evolution of the overall project. As we look at container and pod isolations, what gaps need to be filled to make it easy for end users to adopt safely.

[magowan]

I guess I read part of the text change differently at the time when I provided a review to #5 , I don't see the efforts to date with CC to be an outgrowth of previous kata/sgx work, rather it is an outgrowth of looking at kata with TEE's and in this case we happened to start with pods. But maybe that isn't important, I agree we talked about things in the community call. I also agree that as scope we want to be looking at both pod and container isolation to build things in common but to date I don't feel we have figured out what commonality between pod/container approach looks like especially across quite a few different SGX related projects. So in terms of interesting definitely, and definitely a good example of what we need to look at in much the same way as inclavare or other projects which have presented in meetings are.

I just feel that the demo documentation here should reflect the discussions we have had, agreements we have reached and value this project as brought. If we had a documentation section regarding other projects we wish to align with and what is yet to be done, then considering this in that context fits with the picture in my head.

But to reassure I am onboard that we want to find commonality between pod and container isolation approaches.

And as always we are a community so if it is just me that feels it doesn't quite fit as it is then happy to go with consensus and I repaint the picture in my head and my view on what the demo documentation section is for.

[jiazhang0]

Simply speaking, Gramine LibOS is working as a workload inside container, and Kata (not Kata CC) just passes through SGX capability to Pod (and thus containers). So I think there is a weak link between Kata and Gramine, and there is no link between Kata CC and Gramine.

As James mentioned, it is still unclear the relationship between Pod isolation and container isolation using TEE. Especially there is no hint to prove they can perfectly work together. My point is we should work together to work out a general CC approach based on SGX TEE and explain how a container isolation is implemented with SGX. And this is what Inclavare Containers hopes to archive through providing a general API and framework to interface with SGX LibOS (Actually Occlum and Graphene LibOS have adopted it). Of course this might be not the only method. In any way, it is necessary to be clear to explain how SGX TEE works as a Confidential Containers.

[monavij]

In my mind confidential container project needs to support both VT based confidential containers and native confidential containers. Gramine fits quite nicely with native confidential containers, I don't see confidential container project as ONLY confidential kata containers project, because if that is the case then that is what this should be called.

[sameo]

Hey @monavij

The confidential containers project uses Kata Containers as a way to leverage confidential computing technologies like Intel TDX, AMD SEV or IBM SE, and do k8s pod level isolation. Kata Containers is a tool to build that architecture. We believe it makes also sense to support container workload level isolation through for example SGX, but we are still discussing what would be the best way to integrate that into the confidential containers project. In particular, we want to look at which components could be reused across different implementations, for consistency sake.

The demo @mythi sent is very nice and compelling, we've actually seen it live during one our weekly meetings. However, and given that it's not using any of the other components hosted in the confidential containers org, I feel it's a confusing message that we would send. As an external user, seeing a demo here I'd expect that it's showcasing (at least partially) what this confidential containers project can do. But here it's demoing something that is entirely based on external components that we don't (yet) integrate into the project.

What we have not discussed in details yet is how the current confidential containers project could be expanded to include SGX based container isolation. I believe this should be our first step before merging demos like that one, as impressive as they may be.

[monavij]

Hi @sameo, thanks for your note and it makes sense. Look forward to how the discussion on SGX based containers evolves and hopefully this demo will help with that discussion, as it showcases a bit different use case for how SGX based confidential containers are being deployed today.

[mythi]

closing per our conversation in the community call today.