falcosecurity / evolution Goto Github PK
View Code? Open in Web Editor NEWEvolution process of The Falco Project
License: Apache License 2.0
Evolution process of The Falco Project
License: Apache License 2.0
I am deploying falco on a set of clusters that all have PSPs enabled, we use a default fairly restrictive PSP across the whole cluster which causes this deployment to fail. For the time being I have created an exclusive pod security policy for the falco components to use which allows me to install them without the deployments being invalidated. What I would prefer is a tailored PSP that only allows the features that falco needs and disables the others for security purposes.
I am not sure if this should be a documentation request or a feature request as we could include this in either the helm chart as a true/false value that automatically applies the policy to the target namespace or as an entry in the documentation that lists the required permissions for falco so that users can create the policy themselves.
Description of Request
The following two projects are parts of the libs plugin system proposed by @ldegio:
This request has to be considered as a dependant of:
Motivation
The plugin system for https://github.com/falcosecurity/libs is a new awesome feature under development.
Basically, this new mechanism will allow plugging new data sources to libscap
and libsinsp
so that the library's consumers can use them. Thus paving the way to a lot of new possibilities, really. ๐ฅณ
When the implementation becomes official, other fundamental pieces will be needed, since:
Those repositories are WIPs that aims to address the above topics. The repos also reached a point where feedback is needed, and incubating them at some point would help to test-drive implementations.
Describe the bug
As noted in falcosecurity/falco#2005, the module at https://forge.puppet.com/modules/sysdig/falco does not point to this repository. It also seems that this repo has had enhancements merged since the last release to the Puppet Forge.
How to reproduce it
View https://forge.puppet.com/modules/sysdig/falco
Expected behaviour
I expect the docs in the published Puppet module to reference the current home of the repo.
The https://github.com/falcosecurity/pdig repository is an incubating project that has had no activity since May 28, 2021
I'm unsure if the current @falcosecurity/pdig-maintainers are still interested in maintaining that repository. If yes, please let us know.
Otherwise, if nobody disagrees, we should archive this repository.
Also, please let us know if someone else is interested in maintaining it. It's possible to discuss any revamping proposal at any time, even after the repository has been eventually archived.
Motivation
The Falco configuration and rules files are now statically copied from the current Falco's master version.
Feature
A smarter dependency management solution is needed.
Alternatives
A non-smart but rapid solution could be to point out the user to the available versions of Falco's default configuration and rules files.
Additional context
As for this PR the configuration and rules files are copied only as a temporary solution to the first PR since the integrations were initially intended to be part of the Falco project (and repo).
Since the falcosecurity/probeloader
image is not supported anymore, we need to update the way the initcontainer works here.
Now, the driver can be installed by using the falco-driver-loader
script that's provided within official Falco's images.
Also, I believe that we don't need falcoctl
in this process and the download URL is not needed anymore here since falcosecurity/falco#1158
Additional context
The new approach is going to be documented soon ๐ falcosecurity/falco-website#186
See @leodido comments:
cc @maxgio92
Motivation
I think there are too ways to deploy Falco on top of Kubernetes (deployment VS daemonset + with-RBAC VS without-RBAC + Falco slim container image VS Falco "full" container image).
Feature
I'd maintain only the daemonset solution since the driverloader should run on every node, with RBAC enabled since it is the default authorization mechanism for apps in k8s.
Furthermore, since this is not an official method to deploy Falco (kernelspace and userspace components), I think that it's better to keep it simple.
Additional context
The Falco images are going to be under review; see here for details.
/kind feature
Describe the bug
(Not a bug, but there's not a better category for this issues). We detected that O'Reilly closed down last month the free service that we used to host the labs here: https://github.com/falcosecurity/katacoda-scenarios
Hence, none of this content is available any more. I suggest to archive this repository for now.
How to reproduce it
Just visit katacoda.com or any of the labs.
Expected behaviour
Additional context
Motivation
As discussed with the whole community during yesterday's community call, we're going to move out from the main Falco repository its integrations/
directory.
This relates to the more broader discussion about Falco's official artifacts (falcosecurity/falco#1114).
Feature
Move here the integrations/
directory of Falco.
/assign @maxgio92
Wait for falcosecurity/test-infra#113 to be merged in, thanks! ๐ฅ
Describe the bug
I don't see the value of having a template repository, whose only guarantee is adding a default license and an inaccurate OWNERS
file.
We normally create repositories, and before donating it to falcosecurity
, make sure that the OWNERS and the LICENSE files are in place. The README should also be there with an explanation of the projects and a little overview.
Furthermore, most of the projects under this organization do not use it. It has never been used consistently, and it is not maintained anymore.
Proposal
Given the above, I propose to archive falcosecurity/template-repository
repository.
Description of Request
The following projects (or part of them) are de-facto officially supported:
However, those projects are currently documented as incubating projects. This request aims to regularize their statuses by promoting them to "Official support".
Motivation
By this time, those projects are a fundamental part of the Falco release process and are partially documented on the official website. Some of them provide artifacts distributed along with the Falco official release. Since users recognize them as part of the Falco ecosystem, maintainers regularly keep them up-to-date during the release cycle. Thus, promoting them to "Official Support" is mostly a formality but also a way to document the support level users should expect.
The plan
To satisfy this request, we have to perform just a few small steps (mostly documentation). Here is the list:
NB
In practice, promoting a project just means updating its status within this table.
What to document
What this repo is for, what it contains and/or will contain.
In the README.
Motivation
We recently discussed the future of Falco, and we think it is in good shape and ready to try for CNCF graduation again. However, before submitting the graduation proposal again, some preparation is required. This issue aims to track the progress of this process.
Refs
Action items
Status: work in progress
We will add action items as they come and constantly update this issue with their progress.
[email protected]
๐ cncf/foundation#410Description of the issue
I am setting up falco on Linode kubernetes engine, and was deploying through https://github.com/falcosecurity/evolution.git
falco. Falco pod is not coming and auditsink yaml is failing to install.
How to reproduce it
once clone the evolution repo, deploy yamls from below path
https://github.com/falcosecurity/evolution/tree/master/deploy/kubernetes/kernel-and-k8s-audit
auditsink yaml will fail to deploy as there is no kind
falco pod will fail, due to local package linux-headers-5.8.0-1-cloud-amd64 not available and same is not available on https://download.falco.org/?prefix=driver/2aa88dcf6243982697811df4c1b484bcbe9488a2/
Expected behaviour
Falco pods should get deployed
Screenshots
falco pod failing
aduitsink yaml doesnt deploy
Environment
kubernetes
Additional context
What to document
We need a place to use as a truth where we list what is the status of the various projects/subprojects.
For example:
In some cases, some features or release artifacts of certain projects might not have the same level of the project itself. For example ECR images for Falco are not official support yet.
I want to bring up some issues about the project https://github.com/falcosecurity/kubernetes-response-engine after discussing this in private with @leogr
If the community thinks it's still useful and valuable we need maintainers to step-up and commit to maintain it.
Otherwise, we may need to archive it.
Description of Request
We would like to donate our experimental Libs SDK to falcosecurity.
Motivation
We think that this project will be a catalyst for the adoption of Falco Libs by the community. The Libs SDK simplifies the creation of Libs consumers for different programming languages and provides a recipe for building compact Libs consumer images. Currently, the SDK defines a C API and a Golang wrapper for the Libs, and contains examples of how to build Libs consumers in C, C++, and Go. It can be expanded to support other languages in the future.
As discussed in our community call (4/20/22), a Libs SDK would enhance the Libs ecosystem and enable several use cases. E.g.,
Describe the bug
When installing Falco through the helm chart, this issue falcosecurity/falco#1026, that relates to a wrong setting in the Auditsink, still persists. After setting this to the correct format, as described in this issue, my Kubernetes API log file is full with Error in audit plugin 'dynamic_webhook' affecting 1 audit events: the server could not find the requested resource
errors. Tried generating some Kubernetes audits, that should trigger an alert for Falco as described on the Falco documentation site, but no alert is given. This probably indicates that Falco is not receiving any audit logs.
How to reproduce it
Add the following to the Kubernetes API server:
Set "auditLog", and "dynamicBackend" to true in the values.yaml, provided by the Falco Helm chart.
Install Falco with the Helm Chart with the command: helm install Falco -f values.yaml stable/falco. Used Helm 3.2.1, so the original commands on the Falco Chart Github site won't work anymore.
Expected behaviour
Audit logs from the Kubernetes API server getting received and inspected by Falco.
Screenshots
2020-05-11T11:05:24.005466424Z AUDIT: id="0b967b34-9750-4dcd-905c-cacf392c16c7" stage="ResponseComplete" ip="xx.xx.xx.xx" method="get" user="system:kube-controller-manager" groups="\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="kube-system" uri="/api/v1/namespaces/kube-system/endpoints/kube-controller-manager?timeout=10s" response="200"
E0511 11:16:46.538374 1 metrics.go:109] Error in audit plugin 'dynamic_webhook' affecting 1 audit events: the server could not find the requested resource
Impacted events:
2020-05-11T11:08:12.927495363Z AUDIT: id="d031c5b4-101e-4ba9-964f-fb8cc0b9b402" stage="ResponseComplete" ip="xx.xx.xx.xx" method="update" user="system:kube-controller-manager" groups="\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="kube-system" uri="/apis/coordination.k8s.io/v1/namespaces/kube-system/leases/kube-controller-manager?timeout=10s" response="200"
E0511 11:16:46.581997 1 metrics.go:109] Error in audit plugin 'dynamic_webhook' affecting 1 audit events: the server could not find the requested resource
Impacted events:
2020-05-11T11:02:22.342627937Z AUDIT: id="ec410dc7-8173-4528-aef6-d66a753524df" stage="ResponseStarted" ip="xx.xx.xx.xx" method="watch" user="system:node:workernode1" groups="\"system:nodes\",\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="default" uri="/api/v1/namespaces/default/secrets?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dfalco-token-6z6x6&resourceVersion=33914&timeout=8m14s&timeoutSeconds=494&watch=true" response="200"
E0511 11:16:46.677243 1 metrics.go:109] Error in audit plugin 'dynamic_webhook' affecting 1 audit events: the server could not find the requested resource
Impacted events:
2020-05-11T11:15:01.198249466Z AUDIT: id="0046feb5-dea3-4361-b9e2-3472e01537e9" stage="ResponseComplete" ip="xx.xx.xx.xx" method="get" user="system:kube-controller-manager" groups="\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="kube-system" uri="/api/v1/namespaces/kube-system/endpoints/kube-controller-manager?timeout=10s" response="200"
E0511 11:16:46.880651 1 metrics.go:109] Error in audit plugin 'dynamic_webhook' affecting 1 audit events: the server could not find the requested resource
Impacted events:
2020-05-11T11:01:40.478150167Z AUDIT: id="12f28d4c-4e36-40a5-b3e0-faabb666b17d" stage="ResponseComplete" ip="xx.xx.xx.xx" method="get" user="system:serviceaccount:kube-system:generic-garbage-collector" groups="\"system:serviceaccounts\",\"system:serviceaccounts:kube-system\",\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="<none>" uri="/apis/apiextensions.k8s.io/v1beta1?timeout=32s" response="200"
E0511 11:16:46.903637 1 metrics.go:109] Error in audit plugin 'dynamic_webhook' affecting 1 audit events: the server could not find the requested resource
Impacted events:
2020-05-11T11:12:18.187986702Z AUDIT: id="e53e4dad-9a1d-49d3-95de-f2e26de39259" stage="ResponseComplete" ip="xx.xx.xx.xx" method="update" user="system:kube-scheduler" groups="\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="kube-system" uri="/api/v1/namespaces/kube-system/endpoints/kube-scheduler?timeout=10s" response="200"
E0511 11:16:46.908830 1 metrics.go:109] Error in audit plugin 'dynamic_webhook' affecting 1 audit events: the server could not find the requested resource
Impacted events:
2020-05-11T11:02:00.904053739Z AUDIT: id="e0b80922-c48c-4cbf-86ac-a5e545a5e2dc" stage="ResponseComplete" ip="xx.xx.xx.xx" method="get" user="system:kube-controller-manager" groups="\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="kube-system" uri="/apis/coordination.k8s.io/v1/namespaces/kube-system/leases/kube-controller-manager?timeout=10s" response="200"
E0511 11:16:46.959913 1 metrics.go:109] Error in audit plugin 'dynamic_webhook' affecting 1 audit events: the server could not find the requested resource
Impacted events:
2020-05-11T11:05:43.536143494Z AUDIT: id="855dcc7e-0fad-4d3f-bb8e-e7035adf48e4" stage="ResponseStarted" ip="xx.xx.xx.xx" method="watch" user="system:kube-controller-manager" groups="\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="<none>" uri="/apis/rbac.authorization.k8s.io/v1/clusterroles?allowWatchBookmarks=true&resourceVersion=33914&timeout=9m1s&timeoutSeconds=541&watch=true" response="200"
E0511 11:16:47.060695 1 metrics.go:109] Error in audit plugin 'dynamic_webhook' affecting 1 audit events: the server could not find the requested resource
Impacted events:
2020-05-11T11:08:30.947512433Z AUDIT: id="4c2b9bd7-c162-496b-af08-50e3744a0c5c" stage="ResponseComplete" ip="xx.xx.xx.xx" method="get" user="system:kube-scheduler" groups="\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="kube-system" uri="/apis/coordination.k8s.io/v1/namespaces/kube-system/leases/kube-scheduler?timeout=10s" response="200"
Environment
Additional context
Tried installing Falco as a host-based installation via the script on the Falco documention site. By using this method and configuring the Kubernetes API server, Falco works as expected and no issues appear in the Kubernetes API log.
Motivation
As this repository is becoming more and more critical for decision-making and documenting the whole project, I think it would be a good idea not to mix the documentation with the experimental code. I find it more straightforward and consistent that such source code would live in its repository.
Feature
falcosecurity/contrib
repositoryAlternatives
We might altogether remove the sandbox level. But I'd like that since such experimental code is still important to test-drive ideas or to provide examples.
Additional context
contrib
is the former name of evolution
and has also been suggested by @maxgio92, so I really believe it's the perfect name ๐ธ
Motivation
This issue is a task list of actions to be performed after #169 gets merged.
The motivation to perform some actions after is because #169 is already too big, and some tasks may require PRs in other repositories.
TODOs
falcosecurity/evolution
and update it accordingly to the new governance documentfalcosecurity/evolution
and update the automationcore-maintainers.yaml
file under the falcosecurity/evolution
and create a Falco infra job to update it automaticallyNotes:
For documents to be moved or removed, we will not actually remove them from the origin place. We will instead create an almost empty file that redirects contributors to the new document.
Motivation
Following the discussion on the call today. There was talk of moving a new userspace program into the falcosecurity github org.
We need a few things to make this happen.
Feature
Alternatives
Additional context
Description of Request
@Issif @Kaizhe @Dentrax and I developed a little Go binary that continuously monitors Configmap which includes rules and configuration of the Falco. Whenever the binary sees that there is a change about the rules, it will send a SIGHUP signal to the Falco's container within the same Pod. By doing that Falco can be able to reload itself and continue to work with the new configurations.
Motivation
For motivation see the proposal in Falco repository - PR falcosecurity/falco#1692
Motivation
Since the plugin system comprises several moving parts and many actions need to be performed in the correct order, I created this issue to keep track of their progress. So, what better place than the evolution repository for that? ๐ธ
Overview
Briefly, before releasing the plugin system feature, the following must be completed and incorporated into our GitHub organization:
libscap
and lipsinsp
, in progressTODO list
Some tasks are needed to get the desidered results. Moreover, some of them depend on others that need to be worked on before. So, here is the full task list in the expected order:
plugin-sdk-go
repositoryplugin-sdk-go
repository has been adopted as an incubating project (PR #104)plugins
repositoryplugins
repository has been adopted as an incubating project (plugin-sdk-go
with the version equals to 0.1.0 (DO NOT do that until we assume the APIs are stable enough)Motivation
To Enable K8s Audit Logs in Cloud Environments
Feature
How do we enable k8s Audit logs in AWS,Azure and GCP.
Description of Request
I'd like to add a terrraform module that creates necessary aws cloud resources to connect AWS Cloudtrail with the cloudtrail falco plugin.
The module is at https://github.com/mstemm/falco-cloudtrail-terraform. It was copied almost verbatim from the sysdig terraform module for the cloud-connector, with their permission. That terraform module does a lot more, like deploying sysdig applications in addition to aws resources. I kept just the parts that are used for the single-account
example, which should cover the most common use cases.
Once donated, we can ask users to try it out and then iterate and/or bring over additional features from the sysdig module.
Motivation
The cloudtrail plugin is very powerful, but it requires a fair amount of setup to create the cloudtrail, s3 buckets, sns topic, sqs queue, etc. This automates this process and reduces the friction for users who want to use the cloudtrail plugin.
Motivation
There is no way for Falco to inspect the EKS audit events directly, Because they are being sent to CloudWatch only.
We need to ship EKS api logs from cloudwatch to falco.
https://github.com/sysdiglabs/ekscloudwatch works fine with falco.
We can add this image, and it's deployment to falco helm chart at https://github.com/falcosecurity/charts/tree/master/falco
I am happy to work on this integration.
The https://github.com/falcosecurity/kilt repository is an incubating project that has had no activity since Nov 2, 2021
I'm unsure if the current @falcosecurity/kilt-maintainers are still interested in maintaining that repository. If yes, please let us know.
Otherwise, if nobody disagrees, we should archive this repository.
Also, please let us know if someone else is interested in maintaining it. It's possible to discuss any revamping proposal at any time, even after the repository has been eventually archived.
Description of Request
We need a new repository for the kilt terraform provider.
Motivation
Our project for serverless instrumentation has a new runtime - terraform. In order to publish the provider to the terraform registry (https://registry.terraform.io/) we must name the repository in a certain way - terraform-provider-.*
.
The repository will be used to publish the kilt provider to terraform registry in an automated way (with gh actions and webhooks).
Describe the bug
I know its been mentioned in a few issues but I havent seen any resolution or a lot of discussion - so I was hoping to ask this one again - Trying to deploy a Falco DS on a Kind Cluster - I have tried it on Kind under Ubuntu 16.04 and 18.04, CentOS 8, and WSL2 (I expected WSL2 issues). All have the same issue.
I have added the kernel-headers-$(uname -r) successfully - but still no luck.
How to reproduce it
Base Ubuntu installed - Standard Docker-ce and a two node Kind cluster. Then deploy the Falco DS manifests.
Expected behaviour
A functioning Falco POD(s)
Screenshots
Creating symlink /var/lib/dkms/falco/0.19.0/source ->
/usr/src/falco-0.19.0
DKMS: add completed.
Error! echo
Your kernel headers for kernel 4.4.0-142-generic cannot be found at
/lib/modules/4.4.0-142-generic/build or /lib/modules/4.4.0-142-generic/source.
Environment
Falco version:
0.19
System info:
Standard Falco DS
Cloud provider or hardware configuration:
OS:
NAME="Ubuntu"
VERSION="16.04.6 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.6 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
Kernel:
Linux kind 4.4.0-142-generic falcosecurity/falco#168-Ubuntu SMP Wed Jan 16 21:00:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Installation method:
K8s
Additional context
Tried the same deployment on Kind on multiple Kernels and Linux Distros - same type of issue on all of them.
Hoping to create a lab for work and Falco is an important piece of the lab... Any ideas?
List of unactive/unmaintained projects under the falcosecurity
organization:
Moreover, the above projects:
falco-operator
which was updated for the last time on Jul 30, 2019)OWNERS
file (with the exception of the cloud-native-security-hub-*
project)For the above reasons, I propose to set those projects as archived (using the specific functionality of GitHub meant for this purpose). Ofc, exceptions from that list should be allowed if a project maintainer volunteers to revamp a project shortly.
Description of Request
It will just be a move from the current place (ie: inside the https://github.com/falcosecurity/plugins repo) to a new place: plugin-sdk-cpp
.
Motivation
It does not feel ok to leave the sdk inside the repo that will host Falco plugins provided by falcosecurity.
Therefore, we follow same approach that was taken with https://github.com/falcosecurity/plugin-sdk-go.
Thanks!
Description of Request
Handoff of the VSCode plugin to falcosecurity.
Motivation
It might be in the best interest of the oss team to group all things falco related together.
Description of Request
I started few days ago a new project, a sidekick for falcosidekick
๐.
https://github.com/Issif/falcosidekick-ui
The idea is to get a simple Web UI which displays in real-time the latest events from Falco
.
Motivation
I would like to incubate it and soon release it as an official project. I'll maintain it and @fjogeleit agrees to to do so with me (thanks to him).
The first step would be to migrate my own repo https://github.com/Issif/falcosidekick-ui into main falcosecurity
organization
cc @leogr
Motivation
I'd like to begin an effort to make all the language and terms more inclusive.
Switching to main
is just one small step in that direction.
Feature
Change the default branch of this repository to main
Alternatives
Additional context
What to document
Maintainership in our repository is automated and relies on the OWNERS
file spec
(see https://www.kubernetes.dev/docs/guide/owners/).
However, we have never explicitly documented it. I'd like to document that in our governance.
This idea was initially proposed by @kris-nova in this comment.
The Falco community owns three Katacoda labs available in the Katacoda portal. Currently, although available, they are unmaintained and some parts need some updating work. The repository is currently archived.
For those in the community who might not know about this platform, it enables interactive training for any tool you can imagine. As long as the tool we want to feature in the lab can run in a Linux host, any interactive learning environment can be created. It provides lots of flexibility. It also has base images for Kubernetes (two node clusters).
This request involves the next proposals:
For context: this request was already brought up in the Falco community slack channel but I'd like to formalize this proposal through this Issue.
What to document
The root README should be updated to include the new /deploy directory which contains the unofficial methods to deploy Falco.
/cc @leogr
Motivation
As described in the docker documentation we should update daemonset-least-privilege.yaml to reflect the usage of new images introduced recently.
Feature
falcosecurity/probeloader:latest
with falcosecurity/falco-driver-loader:latest
and update settings as described in the docker documentationfalcosecurity/falco:0.21.0-slim
with falcosecurity/falco-no-driver:latest
and update settings as described in the docker documentationvolumeMounts
and other options reflect the new docker image usageAdditional context
I believe we need a solution to attach the devices set. See the note about $(ls /dev/falco* | xargs -I {} echo --device
in the point 2. of the Docker Least privileged documentation.
/cc @maxgio92
As part of the preparations for our graduation submission, this issue tracks the process of reviewing and cleaning up the OWNERS files of each repository. This is a step for falcosecurity/falco#2106 and follows the community call discussion of 2022-06-29.
The OWNERS files of each repository will be updated to remove maintainers that have been inactive for the past 6 months as for the criteria of our governance (see: https://github.com/falcosecurity/.github/blob/master/GOVERNANCE.md#project-inactivity).
Developer activity is reviewed from the https://devstats.cncf.io/ API (ref: https://github.com/cncf/devstatscode/blob/master/API.md, https://github.com/cncf/devstatscode/blob/master/devel/api_dev_act_cnt.sh). Inactivity means having recorded zero or very little devstats over the past 6 months (2022-01-01 - 2022-07-01).
Inactive maintainers will be moved from approvers
to emeritus_approvers
(see: https://www.kubernetes.dev/docs/guide/owners/#emeritus) so that they will have the possibility to step up again in the future.
If any of the maintainers involved wishes to continue with their role, or to become active again, this issue (or any of its linked PRs) is the right place of discussion.
These repositories are excluded from the rewiew:
Motivation
My repository github.com/kris-nova/falco-trace
Has a lot of work and documentation around running Falco with the new pdig project.
The work here is mostly a toolbox to demonstrate how to run Falco in various ways with pdig, and this could later turn into a go project or even make it's way into the official Falco build.
Feature
Create a new repository and set up our beloved poiana.
Alternatives
Additional context
Description of Request
This is a related to the plugins proposal. The https://github.com/mstemm/plugin-sdk-go/ repository contains support code for writing plugins in Go. We'd like to move this repository under the falcosecurity organization and donate all the code to the falcosecurity organization.
This is a part of 4 changes to add plugins support to Falco:
An earlier incubation request (#62) was created before the proposal was complete and accepted, and covered both the sdk and initial set of plugins. We could repurpose that issue but for the sake of clarity, I created a new issue just to cover the go plugin sdk part.
Motivation
This go module makes it much easier to author plugins in go.
Motivation
In the effort of reducing the scope of artifacts that are officially supported and included in the main repo, we should move https://github.com/falcosecurity/falco/tree/master/examples to here too.
Feature
Create the /examples
directory and copy those files.
Alternatives
Additional context
Another PR in the main repo will be needed to remove them there.
The https://github.com/falcosecurity/client-py repository is an incubating project that has had no activity since Sep 29, 2021
I'm unsure if the current @falcosecurity/client-py-maintainers are still interested in maintaining that repository. If yes, please let us know.
Otherwise, if nobody disagrees, we should archive this repository.
Also, please let us know if someone else is interested in maintaining it. It's possible to discuss any revamping proposal at any time, even after the repository has been eventually archived.
Motivation
Following falcosecurity/falco#1184 I would like for this repository to be a repository that holds the following.
contrib
, repo
, and official
? How do they work? How do you progress?)/contrib
directory which serves as the storage for what is now this repository/official
directory with documentation about our current official support/repo
directory (maybe with YAML like Kubernetes uses for slack channels) that defines our repositories and OWNERSFeature
Can we rename this repository and structure it in such a way that we can automate some of this in the future?
Alternatives
Additional context
Description of Request
Please open a repository called kilt to contain the project described by proposal falcosecurity/falco#1388 and implemented in PR #40. This has already been discussed in the community call.
Motivation
For motivation see proposal in falco repository - PR falcosecurity/falco#1388
Description of Request
I'd like the kernel_crawler from the draios/probe-builder repo to be donated to falcosecurity.
It will be used as a github action to maintain a list of currently available kernels in various distros; the output json will be then parsed by clients (namely, test-infra) to automatically generate driverkit configs.
Note: i'd like to donate my own fork instead: https://github.com/FedeDP/kernel-crawler, as it already provides arm64 support + has already github actions in place.
Possibly, i'd name the new repo kernel_crawler
instead of probe-builder because it will just contain the kernel_crawler part.
Motivation
Lack of prebuilt drivers is nowadays possibly the main adoption friction for Falco. We need a kernel crawler to be able to auto-generate configs for driverkit; draios already has one, so use it!
Motivation
With more and more integrations being baked into the community, can we please
Feature
Alternatives
Additional context
Motivation
It would simplify the CI and all organization-related processes which are currently initiated from this repository.
Feature
test-infra
to evolution
.prow
accordinglyAlternatives
Additional context
cc @falcosecurity/test-infra-maintainers
The https://github.com/falcosecurity/client-rs repository is an incubating project that has had no activity since Mar 5, 2020.
Also, if my understanding is correct, all the @falcosecurity/client-rs-maintainers have stepped down. So the repository is currently unmaintained.
If nobody disagrees, we should archive this repository.
Otherwise, please let us know if someone is interested in maintaining it. It's possible to discuss any revamping proposal at any time, even after the repository has been archived.
Motivation
Following the discussion on the call today. There was talk of moving the existing helm chart to the contrib
status in The Falco Project.
We need a few things to make this happen.
OWNERS
file and append with someone who can maintain and support the helm chart.
โโโ falco-bpf-gke
โย ย โโโ helm.yaml
โโโ falco-grpc
โย ย โโโ helm.yaml
โโโ falco-module
โย ย โโโ helm.yaml
โย ย โโโ PRIVILIGED-WARNING.txt
โโโ falco-operator
โโโ falco-prometheus-full
โย ย โโโ helm.yaml
โโโ falco-systemd
โโโ helm.yaml
Feature
Alternatives
Additional context
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.