Clean up Readme, Add CNCF requested files for project. (#440)

* clean up readme, add cncf requested files

* emails for maintainers
This commit is contained in:
Michael Ducy
2018-10-10 01:50:17 -05:00
committed by GitHub
parent 6445cdb950
commit 0499811762
4 changed files with 115 additions and 10 deletions

39
CODE_OF_CONDUCT Normal file
View File

@@ -0,0 +1,39 @@
## CNCF Community Code of Conduct v1.0
### Contributor Code of Conduct
As contributors and maintainers of this project, and in the interest of fostering
an open and welcoming community, we pledge to respect all people who contribute
through reporting issues, posting feature requests, updating documentation,
submitting pull requests or patches, and other activities.
We are committed to making participation in this project a harassment-free experience for
everyone, regardless of level of experience, gender, gender identity and expression,
sexual orientation, disability, personal appearance, body size, race, ethnicity, age,
religion, or nationality.
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery
* Personal attacks
* Trolling or insulting/derogatory comments
* Public or private harassment
* Publishing other's private information, such as physical or electronic addresses,
without explicit permission
* Other unethical or unprofessional conduct.
Project maintainers have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are not
aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers
commit themselves to fairly and consistently applying these principles to every aspect
of managing this project. Project maintainers who do not follow or enforce the Code of
Conduct may be permanently removed from the project team.
This code of conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a CNCF project maintainer, Sarah Novotny <sarahnovotny@google.com>, and/or Dan Kohn <dan@linuxfoundation.org>.
This Code of Conduct is adapted from the Contributor Covenant
(http://contributor-covenant.org), version 1.2.0, available at
http://contributor-covenant.org/version/1/2/0/

55
GOVERNANCE Normal file
View File

@@ -0,0 +1,55 @@
# Process for becoming a maintainer
* Express interest to the existing maintainers that you or your organization is interested in becoming a
maintainer. Becoming a maintainer generally means that you are going to be spending substantial
time (>25%) on Falco for the foreseeable future. You should have domain expertise and be extremely
proficient in C++. Ultimately your goal is to become a maintainer that will represent your
organization.
* We will expect you to start contributing increasingly complicated PRs, under the guidance
of the existing maintainers.
* We may ask you to do some PRs from our backlog.
* As you gain experience with the code base and our standards, we will ask you to do code reviews
for incoming PRs (i.e., all maintainers are expected to shoulder a proportional share of
community reviews).
* After a period of approximately 2-3 months of working together and making sure we see eye to eye,
the existing maintainers will confer and decide whether to grant maintainer status or not.
We make no guarantees on the length of time this will take, but 2-3 months is the approximate
goal.
## Maintainer responsibilities
* Monitor Slack (delayed response is perfectly acceptable).
* Triage GitHub issues and perform pull request reviews for other maintainers and the community.
* During GitHub issue triage, apply all applicable [labels](https://github.com/falcosecurity/falco/labels)
to each new issue. Labels are extremely useful for future issue follow up. Which labels to apply
is somewhat subjective so just use your best judgment.
* Make sure that ongoing PRs are moving forward at the right pace or closing them.
* Participate when called upon in the security releases. Note that although this should be a rare
occurrence, if a serious vulnerability is found, the process may take up to several full days of
work to implement. This reality should be taken into account when discussing time commitment
obligations with employers.
* In general continue to be willing to spend at least 25% of ones time working on Falco (~1.25
business days per week).
## When does a maintainer lose maintainer status
If a maintainer is no longer interested or cannot perform the maintainer duties listed above, they
should volunteer to be moved to emeritus status. In extreme cases this can also occur by a vote of
the maintainers per the voting process below.
# Conflict resolution and voting
In general, we prefer that technical issues and maintainer membership are amicably worked out
between the persons involved. If a dispute cannot be decided independently, the maintainers can be
called in to decide an issue. If the maintainers themselves cannot decide an issue, the issue will
be resolved by voting. The voting process is a simple majority in which each senior maintainer
receives two votes and each normal maintainer receives one vote.
# Adding new projects to the falcosecurity GitHub organization
New projects will be added to the falcosecurity organization via GitHub issue discussion in one of the
existing projects in the organization. Once sufficient discussion has taken place (~3-5 business
days but depending on the volume of conversation), the maintainers of *the project where the issue
was opened* (since different projects in the organization may have different maintainers) will
decide whether the new project should be added. See the section above on voting if the maintainers
cannot easily decide.

9
MAINTAINERS Normal file
View File

@@ -0,0 +1,9 @@
Current maintainers:
@mstemm - Mark Stemm <mark.stemm@sysdig.com>
@ldegio - Loris Degioanni <loris@sysdig.com>
Community Mangement:
@mfdii - Michael Ducy <michael@sysdig.com>
Emeritus maintainers:
@henridf - Henri Dubois-Ferriere <henri.dubois-ferriere@sysdig.com>

View File

@@ -1,19 +1,21 @@
# Sysdig Falco
# Falco
#### Latest release
**v0.12.1**
Read the [change log](https://github.com/draios/falco/blob/dev/CHANGELOG.md)
Read the [change log](https://github.com/falcosecurity/falco/blob/dev/CHANGELOG.md)
Dev Branch: [![Build Status](https://travis-ci.org/draios/falco.svg?branch=dev)](https://travis-ci.org/draios/falco)<br />
Master Branch: [![Build Status](https://travis-ci.org/draios/falco.svg?branch=master)](https://travis-ci.org/draios/falco)
## Overview
Sysdig Falco is a behavioral activity monitor designed to detect anomalous activity in your applications. Powered by sysdigs system call capture infrastructure, falco lets you continuously monitor and detect container, application, host, and network activity... all in one place, from one source of data, with one set of rules.
Falco is a behavioral activity monitor designed to detect anomalous activity in your applications. Powered by [sysdigs](https://github.com/draios/sysdig) system call capture infrastructure, Falco lets you continuously monitor and detect container, application, host, and network activity... all in one place, from one source of data, with one set of rules.
Falco is hosted by the Cloud Native Computing Foundation (CNCF) as a sandbox level project. If you are an organization that wants to help shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented, consider joining the CNCF. For details read the [Falco CNCF project proposal](https://github.com/cncf/toc/tree/master/proposals/falco.adoc).
#### What kind of behaviors can Falco detect?
Falco can detect and alert on any behavior that involves making Linux system calls. Thanks to Sysdig's core decoding and state tracking functionality, falco alerts can be triggered by the use of specific system calls, their arguments, and by properties of the calling process. For example, you can easily detect things like:
Falco can detect and alert on any behavior that involves making Linux system calls. Falco alerts can be triggered by the use of specific system calls, their arguments, and by properties of the calling process. For example, you can easily detect things like:
- A shell is run inside a container
- A container is running in privileged mode, or is mounting a sensitive path like `/proc` from the host.
@@ -24,18 +26,18 @@ Falco can detect and alert on any behavior that involves making Linux system cal
#### How Falco Compares to Other Security Tools like SELinux, Auditd, etc.
One of the questions we often get when we talk about Sysdig Falco is “How does it compare to other tools like SELinux, AppArmor, Auditd, etc. that also have security policies?”. We wrote a [blog post](https://sysdig.com/blog/selinux-seccomp-falco-technical-discussion/) comparing Falco to other tools.
One of the questions we often get when we talk about Falco is “How does it compare to other tools like SELinux, AppArmor, Auditd, etc. that also have security policies?”. We wrote a [blog post](https://sysdig.com/blog/selinux-seccomp-falco-technical-discussion/) comparing Falco to other tools.
Documentation
---
[Visit the wiki](https://github.com/draios/falco/wiki) for full documentation on falco.
[Visit the wiki](https://github.com/falcosecurity/falco/wiki) for full documentation on falco.
Join the Community
---
* Follow us on [Twitter](https://twitter.com/sysdig) for general falco and sysdig news.
* This is our [blog](https://sysdig.com/blog/), where you can find the latest [falco](https://sysdig.com/blog/tag/falco/) posts.
* Join our [Public Slack](https://slack.sysdig.com) channel for sysdig and falco announcements and discussions.
* [Website](https://falco.org) for Falco.
* We are working on a blog for the Falco project. In the meantime you can find [Falco](https://sysdig.com/blog/tag/falco/) posts over on the Sysdig blog.
* Join our [Public Slack](https://slack.sysdig.com) channel for open source sysdig and Falco announcements and discussions.
License Terms
---
@@ -44,7 +46,7 @@ Falco is licensed to you under the [Apache 2.0](./COPYING) open source license.
Contributor License Agreements
---
### Background
As we did for sysdig, we are formalizing the way that we accept contributions of code from the contributing community. We must now ask that contributions to falco be provided subject to the terms and conditions of a [Contributor License Agreement (CLA)](./cla). The CLA comes in two forms, applicable to contributions by individuals, or by legal entities such as corporations and their employees. We recognize that entering into a CLA with us involves real consideration on your part, and weve tried to make this process as clear and simple as possible.
We are formalizing the way that we accept contributions of code from the contributing community. We must now ask that contributions to falco be provided subject to the terms and conditions of a [Contributor License Agreement (CLA)](./cla). The CLA comes in two forms, applicable to contributions by individuals, or by legal entities such as corporations and their employees. We recognize that entering into a CLA with us involves real consideration on your part, and weve tried to make this process as clear and simple as possible.
Weve modeled our CLA off of industry standards, such as [the CLA used by Kubernetes](https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md). Note that this agreement is not a transfer of copyright ownership, this simply is a license agreement for contributions, intended to clarify the intellectual property license granted with contributions from any person or entity. It is for your protection as a contributor as well as the protection of falco; it does not change your rights to use your own contributions for any other purpose.