[Incubation] KubeArmor Incubation Application

[daemon1024]

KubeArmor Incubation Application

v1.5
This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.

Project Repo(s): https://github.com/kubearmor/KubeArmor
Project Site: https://kubearmor.io/
Sub-Projects: NA
Communication: https://join.slack.com/t/kubearmor/shared_invite/zt-2bhlgoxw1-WTLMm_ica8PIhhNBNr2GfA

Project points of contacts:
Barun Acharya (@daemon1024, [email protected])
Rudraksh Pareek (@DelusionalOptimist, [email protected])
Rahul Jadhav (@nyrahul, [email protected]

Incubation Criteria Summary for KubeArmor

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:
*

Adoption of KubeArmor is tracked in our ADOPTERS.md file.

Owing to the nature of security software, only a small subset are willing to be listed.

Beyond this, we have received interests from other organizations such as:

• LF 5G Super Blueprint to use KubeArmor for 5G security.
• KubeArmor Operator is also available on Red Hat Ecosystem Catalog.
• Securing 5G Control Plane using KubeArmor. [ref1] [ref2]

Application Process Principles

Required

• Give a presentation and engage with the domain specific TAG(s) to increase awareness

KubeArmor was presented to WG Policy in TAG Secuirty on 2021-06-09, and can be discovered at YT Link.

• TAG provides insight/recommendation of the project in the context of the landscape

To be completed by TAG Security.

• All project metadata and resources are vendor-neutral.
  Yes

• Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.

Handled as part of cncf/sandbox#226

• Due Diligence Review.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.

TBD by TOC Sponsor

• Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.

• End User Documentation - https://docs.kubearmor.io/kubearmor/

• Architecture - https://github.com/kubearmor/KubeArmor/blob/main/contribution/KubeArmor%20Design.pdf

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Clear and discoverable project governance documentation.

Project Governance

• Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.

Initial maintainers were from AccuKnox primarily. We have independent maintainers and few other contributors who are shaping up to take the ownership of the modules. KubeArmor now has 8 Maintainers from 4 organizations and 6 Committers from 4 organizations.

Required

• Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

Complete list of current maintainers can be found at MAINTAINERS.md

• A number of active maintainers which is appropriate to the size and scope of the project.
  KubeArmor now has 8 Maintainers from 4 organizations

• Code and Doc ownership in Github and elsewhere matches documented governance roles.

Github Teams reflect the documented roles

• Document agreement that project will adopt CNCF Code of Conduct.
  KubeArmor adopts CNCF Code of Conduct

• CNCF Code of Conduct is cross-linked from other governance documents.
  Code of Conduct referenced in GOVERNANCE.md

• All subprojects, if any, are listed.

NA

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

NA

Required

• Clearly defined and discoverable process to submit issues or changes.

CONTRIBUTING.md

• Project must have, and document, at least one public communications channel for users and/or contributors.

Slack Link documented in README

• List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.

All KubeArmor communications are public

• Up-to-date public meeting schedulers and/or integration with CNCF calendar.

Community Meetings are documented in README
We held biweekly community meetings consistently (total 52 since Sep 2021). The community did not skip a single meeting since its inception. The meeting records can be found in here.

• Documentation of how to contribute, with increasing detail as the project matures.

CONTRIBUTING.md

• Demonstrate contributor activity and recruitment.

The KubeArmor devstats page and dashboards can be found here.

• The community has significantly grown since the project entered the CNCF sandbox.
  • Number of contributors: 30+ -> 150+
  • Github stars: 100+ -> 1070+
  • Github forks: 30+ -> 265
  • Contributing organizations: 5+ -> 30+
• New PRs in last year
• KubeArmor maintainer team has mentored more than 10 candidates as part of LFX and GSoC mentorships.

According to devstats, KubeArmor currently has 252 contributors from 40 companies belonging to 15 countries.

The project averages at ~100 contributions from around ~16 contributors per month according to kubearmor.devstats.cncf.io contained within 30 merged PRs on average per month for the last year.

Engineering Principles

Suggested

• History of regular, quality releases.

KubeArmor uses the semantic versioning scheme.

KubeArmor follows roughly once every two months release cadence with version numbers using format of MAJOR.MINOR.PATCH. The latest release is v1.3.5

We have releases documented at: https://github.com/KubeArmor/KubeArmor/releases.

KubeArmor has a release cadence of once in two month release cycle.

Required

• Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.

KubeArmor supports inline mitigation for preventing attacks. Differentiation Document

• Document what the project does, and why it does it - including viable cloud native use cases.

All of KubeArmor usecase are documented and updated at https://github.com/kubearmor/KubeArmor/blob/main/getting-started/use-cases/hardening.md

• Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

The backlog/roadmap for KubeArmor can be found here.

• Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.

KubeArmor Design and Architecture is documented at - Architecture - https://github.com/kubearmor/KubeArmor/blob/main/contribution/KubeArmor%20Design.pdf

• Document the project's release process.

KubeArmor Release Process is documented as part of Release Wiki

Security

Note: this section may be augemented by a joint-assessment performed by TAG Security.

Required

• Clearly defined and discoverable process to report security issues.

See SECURITY.md

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

We follow Security Practices based on OpenSSF Security Score Card
https://securityscorecards.dev/viewer/?uri=github.com/kubearmor/KubeArmor
It includes

• Branch Protection

• Token Permissions

• SAST

• CI Best Practices

• Document assignment of security response roles and how reports are handled.

See SECURITY.md. All Maintainers are responsible for reacting to incident reports.

• Document Security Self-Assessment.

Being handled in cncf/tag-security#1430

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

https://www.bestpractices.dev/en/projects/5401

Ecosystem

Required

• Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)
  Adoption of KubeArmor is tracked in our ADOPTERS.md file.

Owing to the nature of security software, only a small subset are willing to be listed.

• Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)

Yes

The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.

• TOC verification of adopters.

Refer to the Adoption portion of this document.

• Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.
• KubeArmor provides a way to enforce security in k8s native way by leveraging k8s resource model.
• KubeArmor has integrations with lots of CNCF and LF Projects including:
  • Helm (Installation)
  • OpenTelemetry
  • OpenHorizon
  • Kubernetes PolicyReported CRD
  • Nephio

Additional Information

[daemon1024]

Ref #1235

[angellk]

@daemon1024 @DelusionalOptimist @nyrahul
In preparation for KubeArmor to be picked up by a TOC member after the KubeCon freeze period -- and prior to TOC member assignment -- please:

• review the definition of an adopter
• verify 5-7 project adopters that can and are willing to be interviewed by the TOC reviewer(s) and
  submit information for each adopter to the Adopter Interview Questionnaire form
• complete the Security Self Assessment

[daemon1024]

@angellk ack. On it.

[ssyedhadi14]

Hey @angellk, We are about to submit adopters details in the submission form

What needs to be added in "Link to application tracking issue"?

Thanks!

[angellk]

@ssyedhadi14 please link to this issue - #1326

[ssyedhadi14]

Hey @angellk, We had submitted details of 9 interviewee's details on 17 DEC. Wanted to check the status of the application and next steps.

Wishing you HNY'2025!

[angellk]

Thanks @ssyedhadi14 - have you completed the TAG Security self assessment and linked it to the application?

As everyone is returning back from the holidays a TOC member will also complete another triage and either move the application forward to being ready for DD - or outline any remediations the project needs to take to move forward.

[ssyedhadi14]

Ack @angellk. TAG Security self assessment is complete and submitted - please check - cncf/tag-security#1430