Explore Projects

This project focuses on improving KubeArmor's observability by integrating key Prometheus metrics. The goal is to offer simple explanations for security policy enforcement and alerting within Kubernetes clusters. Key Metrics to Focus On: 1. Number of Policies Applied 2. Number of Alerts Triggered 3. List of Active Policies 4. Policy Status (Active/Inactive) Expected Outcome: Successful integration of these Prometheus metrics, making them accessible via a Prometheus endpoint and adhering to best practices for metric exposition.

Jaeger-v1 has its own Kubernetes Operator (https://github.com/jaegertracing/jaeger-operator) which deploys Jaeger components according to the deployment strategy as well as the database or datastore. The goal of this project is to develop a new operator for [Jaeger-v2](https://github.com/jaegertracing/jaeger/issues/4843) that achieves feature parity with the v1 operator while introducing improvements and new capabilities. This new operator will leverage the [OpenTelemetry operator](https://github.com/open-telemetry/opentelemetry-operator) for Jaeger-v2 deployment while maintaining and enhancing the storage management features from the v1 operator. More details in the [upstream issue](https://github.com/jaegertracing/jaeger/issues/5766). Expected Outcome: By the end of this project, we aim to achieve full feature parity between the Jaeger v2 operator and the v1 operator, with the added benefits of OpenTelemetry integration. The new operator will provide a seamless experience for users, maintaining the robustness and flexibility of v1 while introducing the advantages of v2 and OpenTelemetry.

OpenKruise Agents is a new sub-project of OpenKruise for agent sandbox lifecycle management. Warm pool is a key technology of OpenKruise Agents to ensure the fast sandbox provision. However existing warm pool lacks rolling update capability which makes the warm pool hard to maintain. The goal is to design and implement the basic rolling update capability for SandboxSet, the CRD for sandbox warm pool. - Expected Outcome: 1. The code for warm pool rolling update in SandboxSet 2. Unit and integration tests 3. Documentation for the usage of rolling update in SandboxSet

While generating Package Repository kctrl to create the tar version of the Package Repository instead of pushing the OCI Image to a registry. - Expected Outcome: - Proposal containing design discussions and options considered.

Unit test and e2e test coverage is a critical metric for ensuring code quality and stability. However, many codebases suffer from low test coverage, which increases the risk of release quality, undetected bugs and regressions. We can leverage Large Language Models (LLMs) like DeepSeek to automatically generate unit tests/e2e tests for code with low coverage, then integrate this into CI/CD pipelines to submit Pull Requests (PRs) for people reviewing. Expected Outcome: 1. Research open-source tools compatible with LLM（DeepSeek) for automated unit test/e2e test generation 2. Integrate the automated test generation tool into CI/CD 3. Trigger the tool automatically based on code changes and submit a Pull Request (PR)

Tremor uses its own language for pluggable user defined functionality. The language interconnects internal operators via the connect statement and the select statement. Currently, neither select nor connect verifies that the operator port of the receiving or the sending part is correct ( exists, and is an expected type ) - this can lead to silent or confusing errors. User experience is super important to tremor, so that is a solution state we’re not happy with. The goal of this mentorship is to add validation and provide targeted hygienic errors to users that are trivial to diagnose and resolve as this will massively improve user experience.

The ONAP Portal is a platform that provides the ability to integrate different ONAP applications into a centralized Portal Core. SDC is the ONAP visual modeling and design tool. It creates internal metadata that describes assets used by all ONAP components, both at design time and run time. The SDC manages the content of a catalog, and logical assemblies of selected catalog items --as needed-- to completely define how and when VNFs are realized in a target environment. During the latest release retrospective, the ONAP Integration Team has identified 3 areas of improvements: 1. Integration tests in target deployments using OOM. 2. Improve robot healthcheck across projects. 3. More projects added to CI pipeline and more project-specific testing. This project will focus to address these improvements defined by the SDC/Portal Projects Teams.

OpenELB is an open-source load balancer implementation designed for exposing the LoadBalancer type of Kubernetes services in bare metal, edge, and virtualization environments. Currently, OpenELB supports the BGP protocol. However, the BGP policy is not fully supported in OpenELB. Therefore, based on the BGP protocol, OpenELB is supposed to support the BGP policy to enable leveraging the GoBGP policy feature for controlling the route advertisement.

In the scheduling progress, the karmada-scheduler makes decisions as per a bunch of factors, one of the factors is the resource details of the cluster. We don't want to collect and store each node's resources in detail(That's a burden for Karmada to maintain the information), but we want to build a resource model for each cluster.

Creating applications for the Zowe Virtual Desktop requires a significant amount of programming that can be automated. The purpose of this project is to expand on an existing prototype to make stub application generation a breeze for new comers and future exploiters wanting to experiment with Zowe.

Open source projects should not be hard coded to a particular Database. Armada currently only allows users to use Postgres. This project is to build interfaces around our connections to Postgres so we can allow other databases. Expected outcomes: - A interface is created that allows Armada to interact with any SQL database without exposing implementation details of postgres - increase Test coverage

Currently, Jaeger v1 has an official Helm chart (https://github.com/jaegertracing/helm-charts), but there isn't one yet for Jaeger v2. The goal of this project is to develop a comprehensive Helm chart for Jaeger v2 that allows for easy deployment and management of Jaeger v2 components in Kubernetes environments. This chart should provide flexibility in configuration, support various deployment scenarios, and integrate well with the new architecture of Jaeger v2. More details in the [upstream issue](https://github.com/jaegertracing/jaeger/issues/5767). Expected Outcome: By the end of this project, we aim to have a production-ready Helm chart for Jaeger v2 that is: - Fully functional and tested on the current version of Kubernetes - Well-documented with clear usage instructions and examples - Flexible enough to support a wide range of deployment scenarios - Ready for submission to the official Jaeger Helm chart repository

Implement rust wrapper around aries-vcx to enable consuming the library in mobile setting using modern FFI approach using uniffi library. Additionally implement aries mediator client to unlock full mobile support. Learning Objectives - Learn about self sovereign identity and Aries protocols - Learn Rust language - Learn basics of Kotlin language, basics of Android development - Learn Github Actions and CI process in general - Learn about FFI (Foreign Function Interface) by using uniffi library Expected Outcome - uniffi_aries_vcx rust crate which generate mobile bindings for aries-vcx library - implement mediator client with aries message pick-up protocol support - simple android demo application which can be run in simulator - CI job to build Kotlin and iOS bindings, CI job to test the wrapper

Cluster API Provider AWS (CAPA) enables the creation of Kubernetes clusters in AWS with Cluster API. CAPA allows you create EKS and non-EKS based Kubernetes clusters. When creating a non-EKS cluster we must use AMIs for the nodes in the cluster. The project publishes some AMIs for non-production use. However, the process for publishing the AMIs needs improvment. Firstly we want to fully automate the publication of new AMIs when there is a new Kubernetes version available. Secondly, we need to implement the "AMI Publication Policy" for the project which will involve automated house keeping of AMIs. And thirdly we want to add back support for base operating systems that where temporarily dropped. - Expected Outcome: Automated AMI publication and deletion inline with the projects policy. Support for additional operating systems.

OPNFV VSPERF already includes comprehensive Monitoring solution. However, it lacks the Log-Analysis and Alert-Management solution. This project aims to include log and alert management solutions based on opensources - ELK Stack. This will enhance the ability of VSPERF to: 1. Perform post-test correlation/causation analysis. 2. Adapt the Test-Traffic patterns based on the Alerts. The first aim is to create custom kibana dashboard analyzing and synthesizing VSPERF logs/events. For every test-run, VSPERF generates following logs: 1. vsperf-overall 2. vswitchd 3. trafficgen 4. host-cmds 5. guest-cmds These logs have useful information that can help user to understand the test behavior, and analyze the performance results. VSPERF will have Alerting from the Monitoring component, and lacks alerting from the logs. As the next step, this project aims to use the same information - The logs - and create alerts than will be notified to VSPERF.

<p>Currently, urunc launches sandbox monitors, such as Firecracker and QEMU</p><p>through command-line invocations. This approach offers limited control over the</p><p>sandbox lifecycle once the process is started. On the other hand, most</p><p>monitors expose remote management interfaces, typically through a socket-based</p><p>API.</p><p><br></p><p>These interfaces provide access to the same operations currently performed via</p><p>CLI, but also enable further control over the sandbox lifecycle. In particular,</p><p>they allow more fine-grained lifecycle management of the sandbox, including</p><p>querying and monitoring its state, performing device hotplug and unplug</p><p>operations and interacting with the guest.</p><p><br></p><p>This project aims to extend urunc's sandbox integration layer to support remote</p><p>management interfaces and to explore each monitor's capabilities in order to</p><p>extend the functionalities of urunc sandboxed containers.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- A design document describing the updated architecture and workflow for</p><p>&nbsp;&nbsp;spawning and managing sandbox monitors in urunc.</p><p>&nbsp;- Implementation of the necessary changes in urunc to manage sandbox monitors</p><p>&nbsp;&nbsp;through their respective APIs.</p>

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.

Cartography currently does not ingest many of the AWS resource types used in popular CloudGoat attack/detection scenarios. This mentorship project will extend Cartography’s AWS plugin and schema to cover these missing resources, enabling security practitioners to visualize and query full CloudGoat labs end‑to‑end. The mentee will: i. Audit the AWS resource types used across selected CloudGoat scenarios. ii. Update Cartography’s schema to include each resource, with appropriate labels and key properties. iii. Implement ingestion functions in the AWS plugin, including relationship discovery (e.g., linking log groups to CloudWatch alarms). iv. Add Cypher sample queries and Python examples to the docs demonstrating how to explore one's infrastructure. Expected Outcome: 1) Support for the full list of AWS resources used in CloudGoat (e.g. SSM parameters, CodeBuild projects, CloudWatch metrics/alarms, SNS topics/subscriptions, ECS/EFS resources, Glue jobs, API Gateway, Cognito, Secrets Manager, etc.). a. Full list in the linked issue 2) Automated test coverage for each new resource type. 3) Updated documentation and example notebooks showing end‑to‑end CloudGoat use cases with Cartography.

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