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
The language here implies a documented way of interfacing with Falco, regardless of the programming language.
This is NOT a traditional C/C++ API that we would see in a .h file like we would see in linux or other similar applications.
This is more of a high-level spec or contract (probably implemented via gRPC) that users can count on using, while interacting with the falco core engine. This is similar to a REST API.
The goals would be:
Any language can consume this via a well-known protocol like gRPC
We version this "API" over time, as we make breaking and non-backwards compatible changes
This is more "documentation" than "implementation" (think inputs/outputs)
What would you like to be added:
The concept of an officially supported falco API spec/documentation via a protocol.
This implies alot. Let's look at the envoy project for a quick example. The entire application is configurable via an API. You can see some documentation here. The program is also written in C++ and is commonly vendored throughout the cloud native ecosystem. We should look at enabling our users in the same way.
Why is this needed:
So that non-C++ programers can easily interface, control, and take advantage of the falco system. This would enable a powerful (and extremely fast) eventing system built on falco using the sysdig libraries libsinsp and libscap.
So that users who wish to take advantage of the falco OSS tool can begin to build out their own inputs/outputs/rules for falco (either via falcoctl* or via their own device)
So that we can begin to define the boundaries for falco and what the engine is and isn't responsible for.
**What do we mean by "API"*?
The language here implies a documented way of interfacing with Falco, regardless of the programming language.
This is NOT a traditional C/C++ API that we would see in a
.h
file like we would see inlinux
or other similar applications.This is more of a high-level spec or contract (probably implemented via gRPC) that users can count on using, while interacting with the
falco
core engine. This is similar to aREST
API.The goals would be:
gRPC
What would you like to be added:
The concept of an officially supported
falco
API spec/documentation via a protocol.This implies alot. Let's look at the
envoy
project for a quick example. The entire application is configurable via an API. You can see some documentation here. The program is also written in C++ and is commonly vendored throughout the cloud native ecosystem. We should look at enabling our users in the same way.Why is this needed:
So that non-C++ programers can easily interface, control, and take advantage of the
falco
system. This would enable a powerful (and extremely fast) eventing system built onfalco
using thesysdig
librarieslibsinsp
andlibscap
.So that users who wish to take advantage of the
falco
OSS tool can begin to build out their own inputs/outputs/rules forfalco
(either viafalcoctl
* or via their own device)So that we can begin to define the boundaries for
falco
and what the engine is and isn't responsible for.Notable references for this:
#811
#789
#785
#528
#529
#531
The text was updated successfully, but these errors were encountered: