Skip to content
Open
92 changes: 92 additions & 0 deletions projects/confidential-containers/AccuKnox-interview.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
Interviewee: Rahul Jadhav(nyrahul@gmail.com)

Interviewer: Lin Sun

Company: AccuKnox

Date: 10th Feb 2026

## Questions

#### 1. How long has your organization used the project?

AccuKnox worked on 5G security solution that provided Intent based security for 5G ORAN and 5G Core deployments.
Here is the [sample policy](https://github.com/5GSEC/nimbus/blob/main/examples/clusterscoped/coco-workload-si-sib.yaml) created
that used CoCo for ensuring that the workload is installed on hardware enabled security module.

#### 2. What were the main motivations to adopt the project and which key features do you use today?

5G UDR (Unified Data Repository) is a network function that stores sensitive data such as users' subscription keys and has to be
secured intricately. 5G deployments now readily deploy on public cloud providers and towards this end, the security threat model
is completely changed i.e., we have to assume that the CSP has root/admin access to the virtual machines.
AccuKnox depends on CoCo based deployments to secure such workloads.

#### 3. Compared with other products and projects in this space (proprietary and open) what drew you to the project?

CoCo is the only project that has the full TEE framework towards containerized deployments, including cloud APIs adapter that
make deployment even in cloud hosted env easy.

#### 4. What is the current level of usage (pre-production, production) and scale?

Pre-Production

#### 5. What version of the project is currently in use and what is your update cadence with the project?

We are still using v0.13.0 release of CoCo which is roughly an year old. We haven’t diligently updated the [code base](https://github.com/5GSEC/5g-blueprint-controls).

#### 6. Can you walk me through what your experience was in either adopting it outright or integrating it with your existing services and applications? What challenges did you experience with the project?

We initially struggled to integrate with the AWS version of the CoCo. However, the [Cloud-api-adapter tooling](https://github.com/confidential-containers/cloud-api-adaptor) made it simpler.

#### 7. Did you find the information in the repo or the project docs valuable to your implementation? If so, where did you find the information and what specifically was useful?

The docs were useful, however, we had to reach out to slack for help. Pradeepta and a few other folks helped out earnestly.

#### 8. Did you need to engage with the community members or maintainers? If so, what was the context of the engagement, which communication channels did you use and did it reach an acceptable outcome?

I presented the work we did in 5Gsec to the CoCo community and that's when they advised us to inform as part of adopters list.

#### 9. Has your implementation of the project provided measurable value? Such as reducing manual activities, faster integrations, supported federation/multi-cloud, ease of use, cost savings, etc.

Measurable value is improved security posture. There is no alternative to TEE/CoCo based execution for certain threat models
wherein if one cannot trust the cloud platform provider, then the only hope left is to deploy using CoCo the sensitive workloads.

#### 10. If the project were to be archived now or in the future, what level of difficulty would your organization experience to remove it from your environments? If that were to happen, would you fork and maintain the project to keep functionality, step into a maintainership role within the project, or something else?

Even though we do not have any hard-bound dependencies after the 5Gsec project, I believe that a certain threat model cannot
be handled without the use of CoCo.

#### 11. Is there something you feel that holds the project back from reaching its ultimate potential?

The hardware availability and stability around the interfaces. The cost of hardware is still prohibitively high to be deployed in general scenarios.

#### 12. In your opinion, what could the project improve?

Messaging. The project needs to create awareness around the use-cases. People get bogged down with the gory technical details.

#### 13. What are the overall strengths of the project?

It handles a security threat model that cannot be handled otherwise without the use of hardware enabled security and the project
does wonders for enabling it in the containerized deployment.

#### 14. Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc.

Yes, we want to make it formally as part of AccuKnox Enterprise offerings. The gov/federal depts use-cases are great to be handled using this project.

---
### Maturity Level Survey


#### 1. Do you feel you have a good understanding on the meaning of each maturity level for CNCF projects?

I believe so (but not very strongly). I have been part of a similar journey for another CNCF project (KubeArmor) for which I am the maintainer.

#### 2. Is there information missing regarding the meaning of each different level?

I have read through the information regarding what is required for changing from sandbox to incubation maturity.
Similarly for graduation phase.

#### 3. Do you rely on those levels internally in any way, and if yes how?

Yes, within AccuKnox we want to use Graduated projects only as far as possible. We leverage sandbox or incubation projects only
if we have enough competency inhouse to handle the issues.
96 changes: 96 additions & 0 deletions projects/confidential-containers/IBM-interview.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,96 @@
Interviewer: Lin Sun

Interviewee: Nicolas Mäding (NMAEDING@de.ibm.com)

Date: March 2, 2026

## Questions:

#### 1. How long has your organization used the project?

We started to actively contribute and participated in and promoted the project since it was formed in 2021. We had some internal PoTs and PoCs based on the Confidential Containers Project (https://github.com/confidential-containers)
since then.

#### 2. What were the main motivations to adopt the project and which key features do you use today?

From my point of view this is the most mature CNCF project in this area and has key industry participants contributing and collaborating. We primarily use the s390x and IBM Secure Execution for Linux versions of the project as well as the
Trustee component.

#### 3. Compared with other products and projects in this space (proprietary and open) what drew you to the project?

It has the most references and contributions by various partners and technologies providers, which makes it for me the reference project around Confidential Computing in the CNCF context. There are different products also
regarding non-CNCF based deployments - Kernel-based Virtual Machines (KVM) and Public Cloud (VSIs) - and I believe based on my experience and customer feedback that a community driven project is key for adoption of this technology
in production.

#### 4. What is the current level of usage (pre-production, production) and scale?

In my opinion, production adoptions depend on the availability of additional features like Baremetal support and an established common Trustee flow. This is
work in progress within the project; the TechPreview has been out since 4Q25 and we intend to harden and further improve its design to enable more usecases.

https://www.ibm.com/docs/en/ccro/1.1.x?topic=platform-confidential-computing-linuxone
https://www.ibm.com/docs/en/rhocp-ibm-z?topic=hyper-protect-confidential-container-red-hat-openshift-container-platform-bare-metal-beta

#### 5. What version of the project is currently in use and what is your update cadence with the project?

We are using 0.16.0 and contributing to main. We intend to update the latest version as soon as it becomes available as it is the foundation for our Kubernetes
platform our product is built upon.

#### 6. Can you walk me through what your experience was in either adopting it outright or integrating it with your existing services and applications? What challenges did you experience with the project?

As we intend to adopt the project for Linux on IBM Z and LinuxONE (s390x architecture), the key challenge from my point of view is the focus on Intel/AMD
(x86 architecture) and adoption by Public Cloud Providers rather than on Premises datacenter.

So different adopting and enabling use cases on different platforms leads to different architectural decisions and adoption of changes. The project from my point of view is too focused on getting the Public Cloud adoption progress and
making decisions focused on this deployment model. I acknowledge that x86 is widespread, but a flexible architecture taking different approaches and deployments into account fosters in my opinion innovation and better solutions
for many use cases to come.

#### 7. Did you find the information in the repo or the project docs valuable to your implementation? If so, where did you find the information and what specifically was useful?

The available documentation is sufficient and fine. High-level technology independent architectural pictures are useful in this context.
As this project matures further, thread model documentation will be an important value-add to be made available through the community.

#### 8. Did you need to engage with the community members or maintainers? If so, what was the context of the engagement, which communication channels did you use and did it reach an acceptable outcome?

We have several team members who are maintainers on the project, so we are in communication with the wider community on a near-daily basis via slack, github and the regular Confidential Containers zoom meetings.

#### 9. Has your implementation of the project provided measurable value? Such as reducing manual activities, faster integrations, supported federation/multi-cloud, ease of use, cost savings, etc.

Yes, this project provides a common approach and project across different hardware and system architectures, which has values in my opinion for many as they get an ease-of-use solution with this project across their hybrid cloud
datacenter.

#### 10. If the project were to be archived now or in the future, what level of difficulty would your organization experience to remove it from your environments? If that were to happen, would you fork and maintain the project to keep functionality, step into a maintainership role within the project, or something else?

The impact would be significant, and we would need to investigate options, if that would become a risk.

#### 11. Is there something you feel that holds the project back from reaching its ultimate potential?

Not at this point.

#### 12. In your opinion, what could the project improve?

Be more open to other technologies, processor architectures and deployment models.

#### 13. What are the overall strengths of the project?

As stated, the contributions from so many participants across the industry and technical community.

#### 14. Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc.

We intend to contribute, request features for different solutions, improved user experience, and plan to continue our involvement as products depend on this project and the underlying technology.

---
## Maturity Level Survey

The following set of questions goes beyond the scope of the specific project adoption. Their goal is to benefit from having access to CNCF project adopters and survey their understanding of the CNCF project maturity levels and any reliance on their meaning for decision making. This information should allow the TOC to better document maturity levels targeting adopters.

#### 1. Do you feel you have a good understanding on the meaning of each maturity level for CNCF projects?

Yes.

#### 2. Is there information missing regarding the meaning of each different level?

Not at this point.

#### 3. Do you rely on those levels internally in any way, and if yes how?

Indirectly. The maturity of the projects used are foremost part of our internal risk assessment and are beneficial as this is proof that a given project and/or concept is accepted in the community and industry at large.
84 changes: 84 additions & 0 deletions projects/confidential-containers/NVIDIA-interview.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,84 @@
Interviewer: Lin Sun

Interviewee: Dan Middleton (dmiddleton@nvidia.com)

Date: Jan 23, 2026

## Questions

#### 1. How long has your organization used the project?

Been involved with the project for 2 years. We are maintainers on the project, we are a vendor for the project, along with internal adopters of the project.
[Confidential computing](https://en.wikipedia.org/wiki/Confidential_computing) is a feature for CPUs and GPUs (carve out a protected memory space, such as creating a virtual machine so you don’t trust other tenants on the same host) , and confidential container (CoCo) is a project which helps end users activate Confidential Computing.

#### 2. What were the main motivations to adopt the project and which key features do you use today?

We have 3 motivations:
- Contributor: We want the NVIDIA GPU to be enabled for this project, so anyone who wants to use AI can use this security feature provided by the project.
- Vendor: We are building products that are on top of the CoCo ecosystem. For example, Redhat openshift is a downstream provider for CoCo.
- Adopter: NVIDIA operates a number of internal and external datacenters. Each has security requirements that benefit from Confidential Computing and we like the cloud-native approach provided by CoCo.

#### 3. Compared with other products and projects in this space (proprietary and open) what drew you to the project?

This is really the main project for cloud-native confidential computing. There are a few other projects but project momentum/feature/contributors drew us. Contributors from major cloud providers, hardware vendors, and independent software vendors.

#### 4. What is the current level of usage (pre-production, production) and scale?

Internally pre-production. Externally for other companies to adopt the NVIDIA version, early access version. GA is planned for later this year (end of Q1).

#### 5. What version of the project is currently in use and what is your update cadence with the project?

We are on the latest version, 0.18. We try to update pretty close to each formal release of the project. For teams using downstreams like Openshift, they update according to the downstream cadence.

#### 6. Can you walk me through what your experience was in either adopting it outright or integrating it with your existing services and applications? What challenges did you experience with the project?

Because NVIDIA employs some maintainers on the project, it was pretty straightforward. Some challenges involve other CNCF components… making sure we have an agreed version of containerd for example. These integration points have been improved since.

#### 7. Did you find the information in the repo or the project docs valuable to your implementation? If so, where did you find the information and what specifically was useful?

Good docs throughout the repo. In the last year, there is a single website that pulls docs from multiple places.

#### 8. Did you need to engage with the community members or maintainers? If so, what was the context of the engagement, which communication channels did you use and did it reach an acceptable outcome?

Open community mtg on thurs and we interact live with people there. We also regularly make github issues and the project slack.

#### 9. Has your implementation of the project provided measurable value? Such as reducing manual activities, faster integrations, supported federation/multi-cloud, ease of use, cost savings, etc.

Fundamental security improvement, faster integrations, reducing manual / custom integrations. Without CoCo there isn’t a consistent cloud-native activation for Confidential Computing. An alternative is running kubelet inside a custom Confidential VM, but this doesn’t satisfy all the security objectives provided by CoCo.

#### 10. If the project were to be archived now or in the future, what level of difficulty would your organization experience to remove it from your environments? If that were to happen, would you fork and maintain the project to keep functionality, step into a maintainership role within the project, or something else?
We’ll continue to maintain the project or fork since we are already maintainers of the project. Because all major hardware vendors support Confidential Computing it is difficult to imagine a future where we abandon the cloud-native stack for it.

#### 11. Is there something you feel that holds the project back from reaching its ultimate potential?

We want more end users feedback. More visibility always helps.

#### 12. In your opinion, what could the project improve?

Ease of use, almost nothing in k8s is easy to use :) When it comes to security, details matter. The user is supplied with reasonable security defaults but for their specific requirement they have to tweak the configuration. It would be great if the project can make the configuration much easier.

#### 13. What are the overall strengths of the project?

Security strength along with contribution diversity. In many projects security is an after thought. In CoCo security is a primary requirement.
Additionally, the variety of hardware, cloud, and software vendors participating as maintainers gives us confidence that the project is well balanced and thoughtfully built.

#### 14. Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc.
We’ll continue to add features to our upcoming products through CoCo, such as multiple GPU support for LLMs.

---
### Maturity Level Survey

The following set of questions goes beyond the scope of the specific project adoption.
Their goal is to benefit from having access to CNCF project adopters and survey their understanding of the CNCF project maturity levels and any reliance on their meaning for decision making. This information should allow the TOC to better document maturity levels targeting adopters.

#### 1. Do you feel you have a good understanding on the meaning of each maturity level for CNCF projects?

Yes I understand and worked with other projects going through the maturity levels.

#### 2. Is there information missing regarding the meaning of each different level?

No.

#### 3. Do you rely on those levels internally in any way, and if yes how?

Indirectly. We are less likely to rely on a project that is early in the maturity level. Our primary decision is based on the project features and implicitly our awareness of alternatives.
Loading