This post is is part of a series of articles about How to develop Falco plugins. It's addressed to anybody who would like to understand how plugins are written and want to contribute. See other articles:

• Extend Falco inputs by creating a Plugin: the basics
• Extend Falco inputs by creating a Plugin: Distribute the plugin

• Introduction
• The registry
• Details of your plugin
  • License
  • ID
  • Name
  • Fields
• Propose your Plugin
• Share with the community
• Conclusion

Introduction

In the previous post article we covered all the basics to develop a plugin. In this article, we'll focus on the steps to register and allow the community to use it.

The registration is mandatory for source plugins and optional (but still recommend) for extractor plugins. This blog will talk about the registration of source plugins.

The registry

At the moment, what we call the Plugin Registry is a git repository that centralizes all available plugins through a yaml file.

The table in the README is auto generated by aforementioned registry:

Details of your plugin

In this section, we'll describe the key elements to get your plugin allowed to register.

The registration needs you to create a nice README for your plugin, but also complete all fields for plugins section of registry.yaml, like:

plugins:
    source:
      - id: 2
        source: aws_cloudtrail
        name: cloudtrail
        description: Reads Cloudtrail JSON logs from files/S3 and injects as events
        authors: The Falco Authors
        contact: https://falco.org/community
        url: https://github.com/falcosecurity/plugins/tree/master/plugins/cloudtrail
        license: Apache-2.0

License

You're free to choose the open source license you want, you can check https://choosealicense.com/ for help. Most of current plugins are under Apache License 2.0.

ID

Every source plugin requires its own unique plugin event ID to interoperate with Falco and the other plugins. This ID is used in the following ways:

• It is stored inside in-memory event objects and used to identify the associated plugin that injected the event.
• It is stored in capture files and used to recreate in-memory event objects when reading capture files.

It must be unique to ensure that events written by a given plugin will be properly associated with that plugin (and its event sources, see below).

Name

Each plugin in the registry must have its own name and can be different from event source, that can be shared across different plugins (eg, for k8s audit logs, we may have different plugins but only one type of event source).

The name should match this regular expression ^[a-z]+[a-z0-9_]*$.

Fields

The fields are used for conditions in rules, you must describe the available fields of your plugin in the README.

For example:

Propose your Plugin

Once you're ready, you can submit your plugin to registration:

• fork https://github.com/falcosecurity/plugins
• update falcosecurity/plugins/edit/master/registry.yaml for adding your plugin in the plugins section
• submit your PR to falcosecurity/plugins

Following our Contributing Guide your commits must be signed-off.

You can find more information here.

Share with the community

By sharing your idea and code with the community, you will have direct feedbacks. Don't hesitate to share your work in the Slack kubernetes#falco before submitting your PR too!

Conclusion

You should now be able to propose your plugin to the community and have feedbacks about it. The following posts will describe more advanced use-cases like events from Cloud Services. Stay tuned!

You can find us in the Falco community. Please feel free to reach out to us for any questions, suggestions, or even for a friendly chat!

If you would like to find out more about Falco:

• Get started in Falco.org
• Plugin Documentation
• Plugin Developer Guide
• Plugin registry
• Check out the Falco project in GitHub
• Get involved in the Falco community
• Meet the maintainers on the Falco Slack
• Follow @falco_org on Twitter

• ←Previous
Next→