You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Communication - OpenFGA manages our own communications channels like websites, blogs, social media accounts, and Slack.
Hosting - OpenFGA holds community meetings, events, resources, and infrastructure on vender-neutral, 3rd-party resources.
Architectural decisions - Decisions on OpenFGA's roadmap and direction are facilitated by the opportunity for contributors and adopters to receive consensus on their features, PRs, etc. that promotes shared benefits for all contributing organizations.
Governance - OpenFGA is self-governing, which follows the CNFC Code of Conduct, a documented governance model, and clearly defined roles and responsibilities for project leadership.
Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
Met during OpenFGA's application on 15-03-2024.
Due Diligence Review.
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.
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.
TODO
Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.
TODO
Governance clearly documents vendor-neutrality of project direction.
TODO
Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.
Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).
Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).
Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
TODO
Required
Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.
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.
Open PR Age: 5 hours 1 min median 7 day moving average
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.
As the world continues to move to a more digital, collaborative ecosystem of applications with ever-increasing objects, developers are scrambling to keep up and evolve their authorization systems to be more relationship-focused. But authorization is difficult to get right. OWASP's Top 10 security risks include 3 on Authorization, with the top vulnerability being Broken Object Level Authorization.
Just like Open Policy Agent for cloud infrastructure, application developers want a cloud-native option to add fine grained access control to their application logic without recreating a new solution every time they need to protect a new object type. Centralizing authorization enables application developers to build against a single predictable pattern regardless of their authorization needs. This approach to authorization will continue to serve them regardless of scale or pivoting through a digital transformation journey.
Document what the project does, and why it does it - including viable cloud native use cases.
OpenFGA is a high-performance and flexible authorization solution that allows developers to build fine-grained access control using an easy-to-read modeling language and friendly APIs.
Inspired by Google Zanzibar, OpenFGA is a centralized authorization engine that evaluates decisions by determining whether a relationship exists between an object and a user. Each check request references the authorization model against the known object relationships and returns an authorization decision (i.e. true or false).
Model any authorization system - OpenFGA is inspired by the Google Zanzibar paper for Relationship-Based Access Control, and also solves problems for Role-based Access Control and some Attribute-Based Access Control use cases. The modeling language is powerful enough for engineers to create complex relationships but friendly enough for other stakeholders on the team to read and understand.
Blazing fast - OpenFGA is designed to answer authorization check calls in milliseconds across billions of relationships, which lets it scale with projects of any size. It works just as well for small startups building single applications as it does for enterprise companies building platforms on a global scale.
Works with existing code - SDKs for several of the most popular languages have already been written, making it easy to integrate and grow alongside your applications.
Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.
Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)
A list of OpenFGA adopters can be found at openfga/community/ADOPTERS.md, plus many more that haven’t been disclosed.
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)
Three production examples to highlight:
Canonical
They are embedding OpenFGA into several different layers of their Ubuntu Pro stack.
Configu
Configu is an open source software for streamlining, testing, and automating application configurations across environments. They specifically picked OpenFGA because it was a CNCF backed third-party authorization system that allows them to build upon battle-tested authorization standards saving them valuable implementation time not recreating the wheel for a problem that has already been solved for developers.
TOC verification of adopters.
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.
Refer to the Adoption portion of this document.
Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.
TODO
Additional Information
The text was updated successfully, but these errors were encountered:
OpenFGA Incubation Application
v1.5
Project Repo(s): https://github.com/openfga
Project Site: https://openfga.dev/
Communication: https://cloud-native.slack.com/archives/C06G1NNH47N
Project points of contacts:
Incubation Criteria Summary for OpenFGA
Adoption Assertion
The project has been adopted by the following organizations in a testing and integration or production capacity:
Application Process Principles
Suggested
N/A
Required
Give a presentation and engage with the domain specific TAG(s) to increase awareness
TAG provides insight/recommendation of the project in the context of the landscape
All project metadata and resources are vendor-neutral.
Communication - OpenFGA manages our own communications channels like websites, blogs, social media accounts, and Slack.
Hosting - OpenFGA holds community meetings, events, resources, and infrastructure on vender-neutral, 3rd-party resources.
Architectural decisions - Decisions on OpenFGA's roadmap and direction are facilitated by the opportunity for contributors and adopters to receive consensus on their features, PRs, etc. that promotes shared benefits for all contributing organizations.
Governance - OpenFGA is self-governing, which follows the CNFC Code of Conduct, a documented governance model, and clearly defined roles and responsibilities for project leadership.
Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
Met during OpenFGA's application on 15-03-2024.
Due Diligence Review.
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
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.
GOVERNANCE.md
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.
TODO
Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.
TODO
Governance clearly documents vendor-neutrality of project direction.
TODO
Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.
Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).
Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).
Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
TODO
Required
Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.
OpenFGA has 19 active maintainers.
A number of active maintainers which is appropriate to the size and scope of the project.
Code and Doc ownership in Github and elsewhere matches documented governance roles.
Document agreement that project will adopt CNCF Code of Conduct.
CNCF Code of Conduct is cross-linked from other governance documents.
https://github.com/openfga/.github/blob/main/CODE_OF_CONDUCT.md
Contributors and Community
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
Suggested
Contributor ladder with multiple roles for contributors.
https://github.com/openfga/.github/blob/main/GOVERNANCE.md#roles-and-responsibilities
Required
Clearly defined and discoverable process to submit issues or changes.
https://github.com/openfga/openfga/blob/main/CONTRIBUTING.md
Project must have, and document, at least one public communications channel for users and/or contributors.
https://openfga.dev/blog
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.
https://openfga.dev/docs/community
Up-to-date public meeting schedulers and/or integration with CNCF calendar.
https://openfga.dev/docs/community#monthly-community-meetings
Documentation of how to contribute, with increasing detail as the project matures.
https://github.com/openfga/.github/blob/main/CONTRIBUTING.md
Demonstrate contributor activity and recruitment.
OpenFGA had 91 committers in the last 12 months
Engineering Principles
Suggested
Roadmap change process is documented.
OpenFGA follows an RFC (Request for Comments) process for substantial changes to the project or roadmap
History of regular, quality releases.
Detailed statistics can be found in the following openfga.devstats.cncf.io links:
Required
As the world continues to move to a more digital, collaborative ecosystem of applications with ever-increasing objects, developers are scrambling to keep up and evolve their authorization systems to be more relationship-focused. But authorization is difficult to get right. OWASP's Top 10 security risks include 3 on Authorization, with the top vulnerability being Broken Object Level Authorization.
Just like Open Policy Agent for cloud infrastructure, application developers want a cloud-native option to add fine grained access control to their application logic without recreating a new solution every time they need to protect a new object type. Centralizing authorization enables application developers to build against a single predictable pattern regardless of their authorization needs. This approach to authorization will continue to serve them regardless of scale or pivoting through a digital transformation journey.
A list of CNCF projects that target solving access control in different ways can be found at openfga/community/related-projects.md.
OpenFGA is a high-performance and flexible authorization solution that allows developers to build fine-grained access control using an easy-to-read modeling language and friendly APIs.
Inspired by Google Zanzibar, OpenFGA is a centralized authorization engine that evaluates decisions by determining whether a relationship exists between an object and a user. Each check request references the authorization model against the known object relationships and returns an authorization decision (i.e. true or false).
Model any authorization system - OpenFGA is inspired by the Google Zanzibar paper for Relationship-Based Access Control, and also solves problems for Role-based Access Control and some Attribute-Based Access Control use cases. The modeling language is powerful enough for engineers to create complex relationships but friendly enough for other stakeholders on the team to read and understand.
Blazing fast - OpenFGA is designed to answer authorization check calls in milliseconds across billions of relationships, which lets it scale with projects of any size. It works just as well for small startups building single applications as it does for enterprise companies building platforms on a global scale.
Works with existing code - SDKs for several of the most popular languages have already been written, making it easy to integrate and grow alongside your applications.
Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.
OpenFGA Roadmap
Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.
TODO
Document the project's release process.
TODO
Security
Note: this section may be augmented by a joint-assessment performed by TAG Security.
Suggested
N/A
Required
Clearly defined and discoverable process to report security issues.
OpenFGA vulnerability management is described in the official project security documentation SECURITY.md.
Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)
Document assignment of security response roles and how reports are handled.
Document Security Self-Assessment.
https://github.com/cncf/tag-security/blob/main/assessments/projects/openfga/self-assessment.md
Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.
9.2 OpenSSF scorecard
Ecosystem
Suggested
N/A
Required
Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)
A list of OpenFGA adopters can be found at openfga/community/ADOPTERS.md, plus many more that haven’t been disclosed.
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)
Three production examples to highlight:
They are embedding OpenFGA into several different layers of their Ubuntu Pro stack.
Stacklok
Stacklok recently revamped their authorization model and engine in Minder, an open source software supply chain security platform. They switched from a database-backed authorization implementation using Open Policy Agent to a multi-tenant, relationship-based authorization model using OpenFGA.
Configu
Configu is an open source software for streamlining, testing, and automating application configurations across environments. They specifically picked OpenFGA because it was a CNCF backed third-party authorization system that allows them to build upon battle-tested authorization standards saving them valuable implementation time not recreating the wheel for a problem that has already been solved for developers.
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.
Refer to the Adoption portion of this document.
Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.
TODO
Additional Information
The text was updated successfully, but these errors were encountered: