falcosecurity / evolution Goto Github PK

View Code? Open in Web Editor NEW

47.0 47.0 37.0 722 KB

Evolution process of The Falco Project

License: Apache License 2.0

Makefile 17.51% Go 82.49%

adoption deployment examples falco k8s kubernetes

evolution's People

Stargazers

Watchers

evolution's Issues

Manage falco config and rules dependency

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).

Add plugin-sdk-go repository to falcosecurity organization

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:

Adding go plugin sdk support (this issue)
Adding an initial set of plugins (evolution issue coming soon)
Modifying falcosecurity/libs to add support for plugins (PR coming soon)
Modifying falcosecurity/falco to load plugins and provide them as an event source (PR coming soon)

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.

add ekscloudwatch into falco helm chart to ship EKS audit logs to falco

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.

Create a new repo for Falco cpp plugin sdk: plugin-sdk-cpp

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!

Promote de-facto official projects

Description of Request

The following projects (or part of them) are de-facto officially supported:

Falco Helm Chart
Falco K8S manifest files, which are autogenerated from the Helm Chart
Plugin registry and those hosted plugins bundled in the official Falco package (a notable example is the k8saudit plugin that replaced a Falco core feature)
plugin-go-sdk which is the foundation of officially distributed plugins

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:

Promote https://github.com/falcosecurity/charts to "Official support"
Each chart inherits its status from the related project (the Falco chart will be official, falcosidekick and falco-exporter charts will remain incubating)
Create a repository for K8s manifest files and promote it to "Official support"
Each manifest set inherits its status from the related project
Promote https://github.com/falcosecurity/plugins to "Official support"
The status of each single plugin (or logical group of them)
Promote https://github.com/falcosecurity/plugin-sdk-go to "Official support"

NB
In practice, promoting a project just means updating its status within this table.

Cleanup of on-top-of-Kubernetes solutions

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

Move here the existing integrations from the main Falco repository

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! 🥇

Donate probe-builder/kernel_crawler to falcosecurity

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!

[tracking] cleanup inactive maintainers

Motivation

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:

~~Special repositories~~ (see: #157 (comment))
- ~~falcosecurity/community~~
- ~~falcosecurity/evolution~~
- ~~falcosecurity/.github~~
- ~~falcosecurity/template-repository~~ (see: #154)
Repositories opened less than 6 months ago
- falcosecurity/deploy-kubernetes
- falcosecurity/kernel-crawler
- falcosecurity/plugin-sdk-cpp
- falcosecurity/falco-aws-terraform
- falcosecurity/libs-sdk-go
Repositories that had no activity (or very little) in the past 6 months
- falcosecurity/katacoda-scenarios
- falcosecurity/client-py
- falcosecurity/client-rs
- falcosecurity/kilt
- falcosecurity/pdig

Repositories where inactive owners need to be updated

Revamping interactive learning resources (katacoda labs)

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:

ask to unarchive the repository
taking ownership of the Katacoda repo and any maintenance and new course developments (this is not a requirement, but a proposal. I do not need to own the repository to make PRs and help building new content)
fix the existing labs (I have already identified what needs to be done)
identify and define with the community which new content might be created (I talked with @Issif about a new one featuring the new released Response Engine with falcosidekick)
check if we can embed this labs in a new section in the falco-website
any other educational you might identify as useful for the community. This is not a closed request and will surely benefit from other's feedback! Training is a great way to make tech more accessible and Katacoda provides newcomers a really easy and nice way to get started with a new tool.

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.

List what is sandbox, incubating, official support

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:

falcosecurity/falco: official support
falcosecurity/kilt: incubating
and so on

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.

Falco's examples should be move here

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.

Falcosidekick UI

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

Puppet module docs and release needed

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.

Move `org.yaml` here

Motivation

It would simplify the CI and all organization-related processes which are currently initiated from this repository.

Feature

move org.yaml
from test-infra to evolution.
configure prow accordingly

Alternatives

Additional context
cc @falcosecurity/test-infra-maintainers

Create kilt repository

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

Helm Chart; Auditing not working. "the server could not find the requested resource"

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:

--audit-dynamic-configuration
--feature-gates=DynamicAuditing=true
--runtime-config=auditregistration.k8s.io/v1alpha1=true

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

Falco version: 0.22.1

System info:
{
"machine": "x86_64",
"nodename": "falco-b8kjr",
"release": "4.18.0-147.8.1.el8_1.x86_64",
"sysname": "Linux",
"version": "#1 SMP Thu Apr 9 13:49:54 UTC 2020"
}

Cloud provider or hardware configuration: Kubernetes 1.18.2
OS:
NAME="CentOS Linux"
VERSION="8 (Core)"

Kernel: 4.18.0-147.8.1.el8_1.x86_64

Installation method: Helm Chart

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.

update kernel-and-k8s-audit/daemonset-least-privilege.yaml with new images

Motivation

As described in the docker documentation we should update daemonset-least-privilege.yaml to reflect the usage of new images introduced recently.

Feature

Replace falcosecurity/probeloader:latest with falcosecurity/falco-driver-loader:latest and update settings as described in the docker documentation
Replace falcosecurity/falco:0.21.0-slim with falcosecurity/falco-no-driver:latest and update settings as described in the docker documentation
Remove comments that are not needed any more (ie. this)
Make sure volumeMounts and other options reflect the new docker image usage

Additional 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

Proposal for archiving the `client-py` repository

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.

Document OWNERS file usage

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.

Adopt Falco Trace

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

Plugin system - progress tracker

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:

the Plugin System proposal, already accepted
the Plugin System support in libscap and lipsinsp, in progress
the Plugin System feature in Falco (that depends on the previous point), in progress
the Golang SDK to ease the writing of plugins in Golang, as foreseen by the proposal, inital draft ready
the Plugin repository where concrete plugin implementations will live
the official Plugin Documentation to be included in the Falco's website, draft ready

TODO 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:

/assign @leogr
/assign @mstemm

Adopt pdig

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.

A clear OWNERS file for the new code base
Potentially a repository for the new code? Maybe it should live here?
A build process for the new code
Documentation for the new code

Feature

Alternatives

Additional context

Archive falcosecurity/template-repository

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.

Proposal for archiving the `kilt` repository

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.

Rename `contrib` repository to `evolution`

Motivation

Following falcosecurity/falco#1184 I would like for this repository to be a repository that holds the following.

Documentation on the evolution process (what is contrib, repo, and official? How do they work? How do you progress?)
A /contrib directory which serves as the storage for what is now this repository
A /official directory with documentation about our current official support
A /repo directory (maybe with YAML like Kubernetes uses for slack channels) that defines our repositories and OWNERS
Links to artifacts

Feature

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

Bulk archiving of projects not up-to-date anymore

List of unactive/unmaintained projects under the falcosecurity organization:

Moreover, the above projects:

are being updated anymore for more than 1 year (with the only exception of falco-operator which was updated for the last time on Jul 30, 2019)
do not define an OWNERS file (with the exception of the cloud-native-security-hub-* project)
(most important) are not handled by @poiana (eg. no DCO enforcement).

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.

Update the root README

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

README

What to document

What this repo is for, what it contains and/or will contain.

In the README.

Donate falco-aws-terraform module to falcosecurity

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.

Switch default branch to `main` (evolution repository)

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

falco-kubernetes installation on debian fails

Description 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

Falco version: falcosecurity/falco:latest

System info:

Cloud provider or hardware configuration:
OS:Debian GNU/Linux 9 (stretch)

Kernel: lke16484-20142-5ff7dcfcb4b9 5.8.0-1-cloud-amd64 #1 SMP Debian 5.8.7-1 (2020-09-05) x86_64 GNU/Linux

Installation method:

kubernetes
Additional context

[training] katacoda repo at falcosecurity

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

Consice pod security policy template

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.

Move "sandbox" code to its own repository

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

create the falcosecurity/contrib repository
Move the following directories (preserving the git history) to the new repository:

Update the README.md accordingly

Alternatives

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 😸

Donate plugins repo to falcosecurity

Description of Request

The following two projects are parts of the libs plugin system proposed by @ldegio:

~~https://github.com/leogr/plugins~~ https://github.com/mstemm/plugins this repo will be the place where various plugins will live; currently, it includes four examples
~~https://github.com/ldegio/libsinsp-plugin-sdk-go an SDK for implementing plugins in Golang N.B.: we should change the name of this repo~~ (Moved to a separate issue #101)

This request has to be considered as a dependant of:

The proposal 👉 falcosecurity/falco#1637
The proposed implementation 👉 ~~falcosecurity/libs#33~~ https://github.com/falcosecurity/libs/tree/new/plugin-system-api-additions, no PR yet.

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:

plugins need a place and a registry (a unique ID is required for each plugin);
to facilitate the development of plugins in Golang an SDK is needed (to avoid boilerplates).

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.

[tracking] Governance update follow-up

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

Remove the old falcosecurity/.github/blob/master/GOVERNANCE.md
Remove the old falcosecurity/.github/blob/master/CODE_OF_CONDUCT.md
~~Move falcosecurity/.github/blob/master/CONTRIBUTING.md to the falcosecurity/evolution and update it accordingly to the new governance document~~ We decided to keep it there, since it's required by GitHub as a health file
Move falcosecurity/.github/blob/master/maintainers.yaml to the falcosecurity/evolution and update the automation
Create a new core-maintainers.yaml file under the falcosecurity/evolution and create a Falco infra job to update it automatically
TBD: do we want the maintainers' lists rendered in Markdown?
Update all relevant links across the organization
Create a TOC/header for all documents that include links to other documents so that contributors can reach all docs from one place. See #169 (comment)
Update falcosecurity/evolution/blob/master/README.md to reflect the status of the new governance and other documents.

Notes:
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.

Proposal for archiving the `client-rs` repository

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.

Create a new repo named terraform-provider-kilt

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).

initcontainer in the k8s examples should be updated

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

Move VSCode plugin to falcosecurity

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.

Falco Daemonset of Kind under Ubuntu/CentOS/WSL2 - Same issue

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

Setting up /usr/src links from host
Unloading falco-probe, if present
Running dkms install for falco

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.

Running dkms build failed, couldn't find /var/lib/dkms/falco/0.19.0/build/make.log
Trying to load a system falco-probe, if present
Trying to find precompiled falco-probe for 4.4.0-142-generic
Cannot find kernel config
Thu Feb 13 01:12:53 2020: Falco initialized with configuration file /etc/falco/falco.yaml
Thu Feb 13 01:12:53 2020: Loading rules from file /etc/falco/falco_rules.yaml:
Thu Feb 13 01:12:53 2020: Loading rules from file /etc/falco/falco_rules.local.yaml:
Thu Feb 13 01:12:53 2020: Loading rules from file /etc/falco/k8s_audit_rules.yaml:
Thu Feb 13 01:12:53 2020: Unable to load the driver. Exiting.
Thu Feb 13 01:12:53 2020: Runtime error: error opening device /host/dev/falco0. Make sure you have root credentials and that the falco-probe module is loaded.. Exiting.

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?

Kubernetes Audit Logs

Motivation

To Enable K8s Audit Logs in Cloud Environments

Feature

How do we enable k8s Audit logs in AWS,Azure and GCP.

Proposal for archiving the `pdig` 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.

kubernetes-response-engine

I want to bring up some issues about the project https://github.com/falcosecurity/kubernetes-response-engine after discussing this in private with @leogr

It seems unmaintained since April 2019.
It doesn't have OWNERS file
It doesn't have @poiana handling it
GitHub bot continues to open PR to fix security vulns in its dependencies
It still mentions Falco as "Sysdig Falco"

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.

Adopt helm charts

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.

We should revist the OWNERS file and append with someone who can maintain and support the helm chart
We should compose the helm chart in such a way that we can have multiple charts for various use cases.
We should warn and be very clear about which charts use known attack vectors in Kubernetes (privileged=true)

.
├── 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

Donate libs-sdk to falcosecurity

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.,

Simplification and documentation of a build process for Libs consumers (without requiring expert knowledge of the Libs)
Rapid prototyping of Libs tools for testing new ideas, concepts, automating tasks, etc.
Creation of analytics tools for scap in various languages
Creation of new layers of data abstraction on top of the scap format (e.g., SysFlow)
Enable integrations with data science and analytics frameworks
A playground for the community and Libs contributors to establish and evolve the Libs ecosystem and APIs.

[tracking] Preparation for Falco Graduation

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

relevant community calls: 2022-06-29, 2022-07-06
previous security audit
previous graduation proposal (on Apr 2021)

Action items
Status: work in progress

We will add action items as they come and constantly update this issue with their progress.

Document Adoption Process

Motivation

With more and more integrations being baked into the community, can we please

Document the process requesting for adoption
Document the process of regesting a repository
Add a github issue type each of those to this repo

Feature

Alternatives

Additional context

Falco Hot Reloader

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

falcosecurity / evolution Goto Github PK

evolution's People

Stargazers

Watchers

Forkers

evolution's Issues

Motivation

Repositories where inactive owners need to be updated

Recommend Projects

Recommend Topics

Recommend Org