Explore Projects

Create MeshMark provides a universal performance index to gauge your mesh’s efficiency against deployments in other organizations’ environments. MeshMark functions as a service mesh performance index (a scale) to provide people the ability to weigh the value of their service mesh versus the overhead of their service mesh and assess whether they are getting out of the mesh what they are “paying” for in it. Work with maintainers from Layer5, Intel, Red Hat, and HashiCorp on researching cloud native infrastructure performance. Internship involves: machine learning, adaptive algorithms, running and analyzing performance statistics.

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

Hardware is the base for NFV software deployment. However, it is still difficult to prepare and verify hardware in an automatic way. Based on several Operator's field trail experiences, there is a desire to verify the hardware underlying the stack / infrastructure, with this processing being automated. Initially, this verification would be carried out in labs responsible for the performance of the compliance testing, especially in the future cases examining VNF performance, where hardware will have direct impact. However, the tooling should also apply directly to larger deployments, verifying the hardware, settings, network wiring, etc., which will save valuable time for operators and users in standing up infrastructure.

<p>On the Kyverno website, we want to introduce and document a set of technical outcomes that users can achieve by adopting Kyverno. These outcomes should group together Kyverno’s policy capabilities (validate, mutate, generate, verify images, cleanup) into clear, high-level goals that resonate with platform engineers, security teams, and developers.</p><p><br></p><p>Rather than focusing on individual features, this work will highlight what teams can accomplish with Kyverno in real-world environments.</p><p><br></p><p>Proposed technical outcomes include:</p><p>* Secure-by-Default Kubernetes – Enforce security and compliance policies across clusters automatically</p><p>* Policy-Driven Platform Engineering – Enable golden paths and self-service infrastructure using policy as code</p><p>* Automated Governance &amp; Compliance – Continuously audit, report, and enforce organizational standards</p><p>* Software Supply Chain Security – Verify images, enforce provenance, and reduce risk in CI/CD pipelines</p><p>* Kubernetes Configuration Automation – Use mutation and generation to reduce manual configuration overhead</p><p>* Multi-Cluster Policy Management – Apply consistent governance across distributed and multi-cloud environments</p><p>* AI &amp; Agent Governance – Apply policy controls to AI workloads and agent-driven infrastructure workflows</p><p><br></p><p>Each outcome should connect Kyverno capabilities to real-world use cases, supported by artifacts from the community such as blog posts, talks, policy examples, and reference architectures.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;* A new section of the Kyverno website dedicated to Technical Outcomes, where each outcome includes:</p><p>&nbsp;* A clear description of the problem space and desired outcome</p><p>&nbsp;* Mapping to Kyverno capabilities and policy types</p><p>&nbsp;* Links to supporting resources (blogs, videos, talks, GitHub examples, policy libraries)</p><p>&nbsp;* Optional diagrams or visual flows illustrating how Kyverno enables the outcome</p><p><br></p><p>This section should serve as:</p><p>* A learning and onboarding resource for new users</p><p>* A messaging bridge between technical features and business value</p><p>* A foundation for future content, including case studies, solution briefs, and AI-driven policy generation experiences</p><p><br></p>

Hyperledger Umbra is a Hyperledger Lab designed to run unmodified versions of our DLT platforms (e.g. Hyperledger Fabric, Hyperledger Iroha) under a simulated environment with software defined networking for the purposes of running experiments (e.g. scaling experiments, consensus algorithm development, etc) and security audits. Currently Hyperledger Umbra can run unmodified Hyperledger Fabric Docker images and execute a full Fabric network under simulation. Umbra is written in Python and has code for doing virtual network switches and connections. This project is to extend that code to allow for network fuzzing capabilities. The goal is to be able to introduce packet drops, packet delay, packet reordering, as well as unsolicited packets with random/known-bad data. The purpose it be able to test Hyperledger Fabric's resilience to general network "weather" and intentional attacks coming from the network.

Want to be a cloud hacker? In the cloud, answering the question "who has access to what" is surprisingly complex: we need to know what identities exist, what permission policies and controls apply to them, what resources (storage, compute, networking) exist, what permissions apply to those, and we need to tie those together. Cartography (https://github.com/cartography-cncf/cartography) is an ambitious open source project that aims to do just that. In this project, our goal is to model and map cloud IAM relationships in GCP and Azure so users can answer “who can access what resources” across multi-cloud environments. We previously did this in AWS as seen in “IAM: Whatever You Say I Am”(https://eng.lyft.com/iam-whatever-you-say-iam-febce59d1e3b), and we would love to complete our coverage of this across the major cloud providers. Expected Outcome: 1. Design and implement support for evaluating permission objects in GCP and Azure to draw paths such as (:GCPUser)- [:CAN_READ]->(:GCPBucket) or (:AzureServicePrincipal)- [:CAN_READ]->(:StorageAccount). 2. Bonus: opportunity to author or co-author a blog post or video demo

You will create an AI agent based on open-source Large Language Models (LLMs) running on the CNCF WasmEdge runtime and an MCP server. The application will tie together key components in a modern AI agent stack to create a useful application. The AI agent will ask, answer, and explain practice questions for a specific tech certification program. It enables students to study for the certificate tests more effectively. Expected Outcome: 1. Deliverable 1: create a MCP server with 2 functions a. get_random_question(): The function selects a random question from a list. It returns both the question and the answer. This function is called by the LLM when it detects that the user asked for a new practice question. b. get_question_and_answer(): The function searches an input text from the database for an corresponding question and answer. 2. Deliverable 2: create a practice question / answer database on a subject that you are most familiar with. The MCP functions will 3. Deliverable 3: Create an agent app based on the LlamaEdge framework with a 4. Workflow 1 a. The user asks a question. The LLM calls MCP function get_question_and_answer() b. The agent adds the answer to the context c. The LLM converse with the user with knowledge about the question and its answer 5. Workflow 2 The user asks for a practice question. The LLM calls MCP function get_random_question() to get the question and answer.

Description: UnitedDeployment in OpenKruise enable users to manage a set of k8s workloads in whole while be able to customize the topology and replicas of each workload. This project extends the customization capability to arbitary workload fields by adding common patch fields, so that each subset of UnitedDeployment can have different metadata, container configuration etc. Expected Outcome: Support generate patches for new creating pods of each subset workload while the users can rollout and scale the UnitedDeployment in whole.

For the past two years, the Hyperledger Umbra lab has been worked on by mentees to develop the capability of running the unmodified Hyperledger Fabric docker images under a simulated network environment for the purposes of doing experiments on running Fabric networks in a controlled way. At the end of last summer, Hyperledger Umbra achieved the initial goal of running Fabric networks under simulation. Hyperledger Umbra is useful for doing network-level security fuzzing as well as network scaling experiments and this mentorship is focused on designing and executing scaling experiments. Hyperledger Fabric networks are designed to scale up fairly easily, however nobody has actually tried scaling Hyperledger Fabric to many hundreds and thousands of nodes and done analysis on how it affects the characteristics of the distributed system such as time to reach consensus, time to run an election for block creation, etc. The mentee chosen for this project will work with their mentor to design a plan for setting up, executing, gathering and analyzing data, and reporting the results of scaling experiments run at different scales.

Hosted at play.meshery.io, build a unique learning environment for learning modern application networking through Meshery's support of every service mesh, orchestration of Kubernetes, and integration with many other CNCF projects. Meshery's genesis is that of helping teach people about service mesh technology and enabling to operate this type of cloud native infrastructure confidently. The proposed project is aimed at furthering this mission with interactive API documentation connected to a cloud native playground (a running instance of Meshery).

Develop a Cactus Chia connector plugin + test infrastructure (container images, container manager class, etc.) from scratch. Include end to end test cases powered by Jest and the said testing infrastructure that prove that the connector is working as intended with a locally simulated Chia network. You will be creating a new package in the Cactus monorepo from scratch under the packages/cactus-plugin-ledger-connector-chia/ path. All the information presented here can also be found at the GitHub issue tracker of Hyperledger Cactus, filed under issue #1634 => github.com/hyperledger/cactus/issues/1634

Inspektor Gadget is an eBPF tool and systems inspection framework for Kubernetes, containers and Linux hosts. Previously, Inspektor Gadget had a set of built-in gadgets. We are now moving to image-based gadgets where users can develop their own gadgets in eBPF and host them in OCI registries. But we don't have a test framework to help gadget authors to test their gadgets. This project will focus on implementing such a framework, possibly taking inspiration from the existing framework for built-in gadgets. The documentation for gadget authors should be updated. This project has the opportunity to expand beyond testing, to work on the gadget development experience over all, for example by creating a github template for gadget development. Expected Outcome: Gadget authors can test their gadgets

The Hash Time Locked Contract (HTLC) is a well-known pattern for dis-intermediated asset swaps, i.e., as a mechanism to exchange assets between two parties in two different blockchain networks in an atomic manner without a trusted mediator (or trusted third party). HTLC support has been implemented in the Hyperledger Weaver Labs project, with mechanisms to lock, claim, and unlock assets supported in both the contract and higher application layers. At present, the protocol requires several manual steps by the application users carrying out the exchange or agents acting on their behalf. We would like to automate this process as much as possible by augmenting the relay module in Weaver to communicate events and trigger transactions in foreign networks; this requires both research and software development. Further, HTLC is known to have flaws that could violate system integrity properties, because it relies on parties to execute certain actions by a certain timeout or forever lose the opportunity to carry out those actions; this makes the basic protocol intolerant to system crashes. Research is needed to (provably) determine the best way to make the HTLC protocol fault tolerant, using the features of the blockchain networks maintaining the assets and the Weaver relays mediating the exchange. Augmenting the existing HTLC mechanism within Weaver will provide practical validation of this research.

The component-model proposal merges and supersedes the Module Linking and Interface Types proposals. With this feature, WasmEdge can execute multiple modules wasm with Module Linking and and more flexible types with Interface Type.

This feature request aims to automate the building and publishing of OS images that are used in Kubespray CI testing. Currently, these images (defined in `test-infra/image-builder/roles/kubevirt-images/defaults/main.yml`) must be manually created and pushed by maintainers. Automating this process would reduce manual work, eliminate bottlenecks when maintainers are unavailable, and could include automatic cleanup of outdated or unused images, while still retaining images needed for older supported release branches. - Expected Outcome: A CI job (likely post-merge and possibly periodic) that automatically: 1. Builds the required Kubespray OS images used in CI for tested distributions. 2. Pushes these built images to the appropriate registry. 3. Cleans up old or no longer needed images but retains those required for supported release branches.

Vitess is a CNCF project that has been around for a while. It has a strong community of users and contributors. We want to continue growing this community and make sure that everyone feels welcome and included. Expected Outcome: The mentee is expected to evaluate contributor ladder schemes and rewards and produce a recommendation for the Vitess maintainers. Once a decision is made, the mentee is expected to implement the decisions from the maintainer team. The mentee is expected to collect data about Vitess usage from the community and publish the highlights as a blog post. The mentee is expected to review the Getting Started docs (https://vitess.io/docs/20.0/get-started/) on the Vitess website and enhance them to improve the onboarding experience. The mentee is expected to research and recommend marketing opportunities for Vitess. These could be guest blog posts, podcasts, live streams etc.

Extend KubeArmor features to non-Kubernetes environments by implementing karmor recommend for host policies and unorchestrated containers, and enabling dynamic configuration for default posture and visibility through kubearmor.yaml, a new gRPC service, and karmor commands. Enhance karmor profile for host logs, support karmor install for VMs, and validate policies for non-Kubernetes setups. Expected Outcome: User friendly KubeArmor functionality including Application Behaviour and Policy Management in non-Kubernetes environments.

All In is a community dedicated to advancing diversity, equity, and inclusion within open source. All In for Students is a paid, 12-month program for select college students from underrepresented backgrounds. During the program, students will receive professional development training, open source education, a structured 12-week open source project, and ultimately have the opportunity to join one of our corporate partners for a summer internship experience.

Envoy is an open source edge and service proxy, designed for cloud-native applications.

FINOS (FinTech Open Source Foundation - part of the Linux Foundation) is looking for a summer marketing intern to assist with: - Marketing research (members, projects, BD) - Social media (research, operations) - Content for website (research, operations) - Podcast production (research, operations)

The RISC-V Mentorship Program enables one or more 12-week internship-style projects per session, funded by RISC-V, to match mentors/project leaders together with mentees/interns . Mentees are guided through a series of milestones by one or more project mentors, with whom the mentees meet on a weekly basis. Convolution is the core operation of deep learning models and computer vision applications. MLIR supports various convolution operations. Our project is to vectorize them for the RISC-V backend. There are several methods to implement convolution vectorization, such as optimizing nested loops, implementing vectorization algorithm, converting to GEMM, etc. This project needs to choose a vectorization method and implement a conversion pass for the convolution operations. As for the vector semantic support, MLIR has the “Vector” dialect for the general vector abstraction, and it also allows the backend-specific vector dialect, such as the “x86vector” dialect, “arm_neon” dialect, and “arm_neon” dialect. Like these dialects, the project also needs to propose an “RVV” dialect and work with existing dialects and tools. Deliverables: - An MLIR “RVV” Dialect. (Operations in the dialect can support the convolution vectorization) - A conversion pass to vectorize convolution operations in “Linalg” dialect with “RVV” dialect enabled. - A conversion pass to lower the operations in “RVV” dialect to “LLVM IR” dialect. - Unit tests for “RVV” dialect and conversion passes.

The Software Package Data Exchange (SPDX) is an open source standard for communicating software bills of material information (including components, licenses, copyrights and security references). To support SPDX, an online tool has been developed which provides an easy all-in-one website to upload and parse SPDX documents for validation, comparison and conversion and search SPDX license list. This project will provide enhancements and support for the online tools including: - More automated and high-quality deployment for software updates - Removing some of the dependencies on a Python Java Bridge by moving features like license matching over to a native Python implementation - Improving performance and quality of the online tools implementation

Hyperledger Cactus is a blockchain decentralised integration tool designed to allow users to securely integrate different blockchains started by companies Fujitsu and Accenture. Cactus has pluggable architecture which makes easy to integrate various blockchain by creating plugin, currently plugins for Fabric, Besu, Quorum are implemented. Cactus allows to transfer not only assets but also data between multiple blockchains. On the other hand Iroha (version 1.x) is great with asset management, and has functionality to store data, which makes those two projects a perfect fit! With this internship we will not only allow the interoperability between different blockchains but also create a system of Iroha networks that will also demonstrate the integration in examples easy to run by everybody. The mentee will be able to learn: 1) ways of integrating different projects from architectural point of view, 2) architecture of Iroha (1.x) and Cactus, 3) work in true spirit of open-source, communicating with both Iroha and Cactus community, joining calls and using other community tools, 4) writing documentation, so anyone in the community could use the results of their work, 5)following rules and standards of open-source projects created by hyperledger Expected Outcome 1) Documented, ready-to-use integration of Iroha and Cactus, 2) Documented example of integration between multiple (two and more) iroha's networks with Cactus, 3)Documented example of integration between Fabric and Iroha