The near future of Kata Containers: How do you see yourself contributing to moving the project forward?

[fidencio]

This time, IMHO, is the most interesting time for Kata Containers, as we've seen a lot of traction coming from different areas, and a lot of ideas floating around that can hugely benefit the project.

To name a few of those, we're talking about:

• Remote Hypervisor, which can accelerate the adoption of Kata Containers in CSPs that do not provide VMs with nest capability
• Confidential Containers, which became its own project but heavily relies on Kata Containers
• Rust everywhere, with the addition of the runtime-rs and plans for getting it as the default runtime for v4.0.0
• Windows Containers support on Kata Containers, allowing using the same (Linux) infra for running both Windows and Linux containers
• Better device management being added to, finally, consolidate this in a sane way in the Kubernetes world

From those topics, or even if there's something I didn't mention, how do you plan to work / influence / push for those and help the community to achieve a solid v4.0.0 release and get broader adopted? What are the most important ones for you?

I know the A/C is not related to companies, but I'd also be interested to know what kind of commitment level you can levarage from your direct team to work on the things that you consider important for the project and the community.

[fidencio]

/cc @sameo, @bergwolf, @amshinde, @fengwang666, @jepio, @stevenhorsman

[stevenhorsman]

The main areas that I see myself (and my team at IBM) contributing to are:

• Confidential containers - I've been one of the key contributors since development started in this area, working in most areas there and as confidential-containers is a key part of IBM's plans we will continue to be involved in dev/test/CI-CD and release processes there, with a focus on how we can get the CC features integrated into the main branch in a controlled way, ensuring that Kata's standards of quality and reliability are no compromised.
• Remote hypervisor/peer pods support - this feature came out of my department's research team and on collaboration with Red Hat and Microsoft, we've been pushing the development of this forward a lot in the last year. Again this is a strategic plan of my team, so we'll be continuing to work on this - enhancing the testing and CI/CD and helping to make the feature move from the experimental/beta status it is in at the moment, to be product ready
• CI/CD and testing - lots on my time has been involved in helping add tests and support CI/CD pipelines in the confidential containers space. I believe this is essential to have a reliable and stable project, so plan to continue contributing to this, particularly the CC pipelines as we try and get them merged into main.

I'm interested in the other areas mentioned, moving to rust, Windows support and device management, but they aren't currently my area of speciality, or in my team's direct priorities, so my contributions in those areas is likely to be significantly lower than the above areas.

[bergwolf]

Let me split my answers into two parts.

First, I won't not be able to join the development for all the areas of the project. So I would be more focused on the rust runtime/agent/vmm part most of my time. But, same as before, I would definitely want to be involved in the key design discussions in all areas including but not limited to the ones listed here. In the past, I did play my part in the remote-hypervisor and kata-native device handling designs. In the future, I would like to do so in the confidential container and windows container part as well.

Secondly, the Ant Group Kata team manages large-scale Kata deployment in production. We are very committed to the success of the project and would definitely continue contributing as before. To be specific, we'll continue contributing to the rust runtime/agent/vmm as well as device management areas. It is a top priority for us to ensure that Kata 4.0 has a production-ready rust runtime. And we have plans for the confidential containers and windows container support too.

What's more, we are exploring a new area where we can deploy service mesh securely with Kata, which was explained briefly in the last vPTG and more details will be posted soonish. We believe that service mesh and app runtimes can be served better in the new model.

Cheers,
Tao

[jepio]

Remote Hypervisor, which can accelerate the adoption of Kata Containers in CSPs that do not provide VMs with nest capability
Confidential Containers, which became its own project but heavily relies on Kata Containers

My day to day revolves around confidential containers, so I will continue being most active in the core CoCo project. One item I've been meaning to add to our CI is SNP testing on Azure. I also plan to focus on the generic KBC/KBS work, as I think that is an area that needs work before it is production ready. And finally: easy to follow deployment guides for CoCo 😄

There's a lot of things that still need building, while at the same time we need to pay down some of the accumulated tech debt. It's a balancing act but I'm sure we'll manage.

The Remote Hypervisor work came out of CoCo, and I work closely with people who have been involved in this work for quite some time. I'm happy to help them out in any way I can and make sure they continue being able to push that project forward. There is a lot to be done as well - cloud resource lifetime management needs to be more robust, and we need to work on integrating storage drivers.

Rust everywhere, with the addition of the runtime-rs and plans for getting it as the default runtime for v4.0.0

I'm not going to lie - I don't think "rust everywhere" is the greatest idea. Not everything is a nail, and sometimes the right tool is not a hammer. When integrating with the containerd/kubernetes world, I think it is advantageous to leverage what other projects are building and keep things approachable for that ecosystem - which is written in Go.

I'm not a blocker, but I will offer my perspective on this matter.

Windows Containers support on Kata Containers, allowing using the same (Linux) infra for running both Windows and Linux containers

If someone is interested in working on this, I'm sure I can connect you to someone who knows Windows Containers (😉).

Better device management being added to, finally, consolidate this in a sane way in the Kubernetes world

I'm eager to learn more about this.

I know the A/C is not related to companies, but I'd also be interested to know what kind of commitment level you can levarage from your direct team to work on the things that you consider important for the project and the community.

I know a lot of people within Microsoft working on deploying Kata Containers and Confidential Containers. I already work with these teams and intend to continue working to make sure that:

• what is being built is upstream-able (=serves the interests of the whole community)
• covered by automated tests
• and will guide them through the contribution process.

But I also treat everyone contributing to the project (regardless of employer) with the same courtesy. This way we ensure the project keeps growing, stays inclusive and continues scaling without falling on the shoulders of too few people.

[sameo]

Nowadays I'm mostly involved with Confidential Containers, and one area of that is very interesting to me is the remote attestation one. I think the lack of end-to-end open source solution for attestation services is an industry gap, one that's slowing the Confidential Computing adoption pace down. I believe that Confidential Containers and Kata can naturally fill that gap, not only by providing a full, production ready implementation, but also by providing the right and secure environment where to run these critical services in.

Another topic that I'm currently working on is trusted I/O, i.e. the ability to directly assign physical devices to confidential VMs or containers. Although I'm currently working on the lower layers of the stack, all of it will be useless if we don't also work on making sure Kubernetes finally manages devices in a proper and scalable way. So I'm planning to help making sure Kata Containers supports those new interfaces and also seamlessly integrate with the trusted I/O components we're defining (e.g. with a new trusted devices manager component running alongside the AA).

As for Rust everywhere, and although Rust is my go-to language for almost everything nowadays, I am sharing @jepio views here. We have to be pragmatic and make sure we don't dogmatically push Rust for the sake of it. In some areas (like e.g. the Kata runtime or our guest components), Rust makes perfect sense. In other topics, where the rest of our surrounding ecosystems is a golang place for example, I think we have to favour contributor adoption and welcoming over our favorite programming language.

[fengwang666]

My involvement in the project has always been focused on adopting Kata Containers for running multi-tenant workloads in the cloud. While Kata Containers seems to be the missing piece for supporting hard multi-tenancy in Kubernetes, unfortunately, we haven't seen widespread adoption of Kata in those use cases. As I mentioned in my answer to another question, I believe the lack of production maturity and a steep learning curve are the two main challenges.

Although I can't commit to how much I will be involved in some parts of the project, such as confidential computing and Windows containers, I'm committed to improving the overall production quality and readiness of the Kata Containers project and making it more accessible to everyone. As my company is adopting Kata Containers in production, we plan to upstream bug fixes, operational improvements, and performance enhancements.

I'm particularly interested in contributing to the security aspect of the project, such as vulnerability management. Security is one of the main benefits that Kata Containers brings to the table, but ironically, the entire stack of Kata Containers is complex and can be a security nightmare. As a community, we haven't invested enough in security management.

I'm also optimistic about the benefits that the Rust runtime brings to the project and would like to contribute to the runtime-rs to make it production-ready and eventually replace the Go runtime.