 Welcome from the maintainers of Falco to its maintainers' track. During this talk, we're gonna move on, like real Italians do, to show you the amazing things that happened to Falco in this community in 2020. Last but not least, we're gonna dive into the contribution of the libraries that gave Falco its magic to the CNCF. Yes, we finally did it! Contributing Labescap, Labesins, the kernel module and the VPF probe to the open was one of my innermost desires since the first day I started working on Falco. Anyways, I'm Leonardo Di Donato, as you probably already know, one of the maintainers of Falco. Feel free to just call me Leo, but let me give the floor to another Leo. Hey, I'm Leonardo Grasso. Initially, I started as a Falco contributor and became a Falco maintainer during the last year. The other Leo and I are here to present the excellent work the maintainers in the whole community are doing. Let's start with a bit of history. Falco was created as an open-source project by Cystic in 2016, and it was donated to the CNCF in 2018. Finally, in early 2020, the CNCF promoted Falco to the incubation level. Falco has been the first ever runtime security project to be promoted to the CNCF incubation level. Yay, 2020 Falco started to fly really high. It was an extraordinary year for Falco and its community, and I guess 2021 is gonna be even more remarkable. In just one year, so many goals have been achieved. Even through the time would not be enough to tell them all, we will strive to share the most important with you. First of all, the Falco release process is now fully open-source. Maintainers propose themselves during our community goals so that they can lead the next Falco release. Which happens roughly every two months. Having an open-source release process was a mandatory requirement that came out from the process to move Falco into the CNCF incubation level. Now, and for almost a year already, every merge in the Falco master branch or every git tag on it triggers respectively the release of a development version of Falco or the release of a stable version of Falco. We use the git tab milestones for the stable versions. We enforce a current and precise somewhere to a versioning scheme. We finally split the Falco drivers version from the Falco version. We ship the RPM tarbol packages and container images on the Docker app and on the Amazon ECR gallery. But don't be scared, the process is fully automated. We set up release teams for stable releases only to ensure that all the preconditions are met and nothing's gonna break. Yeah, we are really serious about it. We documented the whole process in the release.md file to take a look at it. In the meantime, join our community goals every Wednesday and propose yourself to be part of the release team for the next Falco stable release. 2020 was also the year when the effective number of contributors to Falco and the Falco security repository grew so much. I guess it's the effect of the pandemic, right? Not sure about this, but hey, this year we had contributors from Amazon people, Delta 3, IBM, the list goes on. Yeah, it's thanks to them that we had the worst power to complete an open infrastructure to handle everything around Falco and its projects from the contributing workflows to the build system and to the test suites. I want to thank all the Falco Infra working group participants publicly. Two of them, Jonah from Amazon and Max from Delta 3 are now maintainers of the Falco Infra and I'm barely capable of expressing my gratitude to them for this. Hey Leo, can you explain what's concretely the Falco Open Infra? Sure, it's a Kubernetes cluster kindly provided by Amazon on the CNCF AWS account on which we run a fully-featured Pro instance. It's fully reproducible and all of its source code is in the testing for a repository. We use the Pro plugins to run our Hoyana bot. We also create Pro jobs to implement build and test pipelines for various projects. For example, this is how we ship more than 3000 pre-built Falco drivers to our users. Oh yeah, do-do. But we also use it to create automations. For example, I recently created a Pro job to automatically update the list of all the maintainers of the Falco security organization. Yes, I saw it. It inspired me to create a Pro job for automatically generating manifest files to deploy Falcon Kubernetes. Although we have provided some examples, those examples were usually not really up to date. But I knew our Falco M chart was working fine and could generate those manifest. So I said, why not automatically generate them when the M chart gets updated and I did it by implementing a Pro job? Thanks to our infra, we don't have to update them manually anymore. Awesome, Leo. Anyways, time to stop talking about our in-house CICD systems. In the deck you can find some useful links, especially the blog post on the AWS blog about Falco creating an open infrastructure with Pro on top of EKS, or my talk about Pro at previous Cubicons. Okay, let's talk a bit about how we renewed the way we distribute artifacts. By taking advantage of the infra, we organize how we store the package and the pre-built drivers. You can finally find all our officially supported art, the fact at download.falco.org. Yeah, we build driverkit to let our users manually pre-build the Falco drivers. Then we created that drivers build grid, which sources links to two slides before, using driverkit on top of our Falco infra. This means that Falco pre-built drivers are possible thanks to Pro and Kubernetes on AWS. Take a look at download.falco.org in the drivers directory to find all of them. There are so many. By the way, recently we also migrated the packages, initially published on the intray, which now is no longer a Bible. Basically, from now on our user can find all they need in one place, which is fully managed by Falco maintainers and bagged by our infrastructure. Okay, we have talked about many topics, but I believe that now is the time of the most exciting, probably the most important, think that happened in February 2021. All of the core components of the Falco stack are now part of the CNCF. As you already know, we announced that the contribution from Sysdig of the kernel model, the EBB probe and the libraries to the cloud native computing foundation. The source code of these components has been moved into the Falco organization. This contribution is fundamental part of a broader process of completely open sourcing one of the more complex and widely adopt EBPF programs, focused on runtime security, together with two fantastic libraries for enriching kernel events. The whole process is outlined in a proposal that Lorenzo and I presented and discussed with the Falco community during the past year. You can read it in the proposal folder or the Falco repository following the links in the slide too. These components are at the base of Falco, which mainly operates on top of our data source, system calls. The drivers, either kernel module or a EBPF probe, collect the system calls. Then the collected data needs to be enriched before being consumed by Falco. In the enrichment phase, the few libraries with synths and libscap take place. This contribution completes the effort of making sure that community worldly homes Falco and all its underlying components, it took a bit of time because it involves separating the pieces that were initially part of Sysdig and making them independent. But from now on, also other projects can benefit from them. We are thrilled to see what folks will build upon these libraries. And there is more. We are actively working on making these components even more awesome and consumable by the community. For example, we are improving the build mechanism, implementing a robust test suite, documenting the API and many other things. So stay tuned. Our part is over. While you watch Thomas speaking of its fantastic Creature Falco sidekick, we go grab some really good Italian espresso. We'll wait for your questions at the end of the talk. Ciao! Welcome to the second part of Falco RNG. In this one, I will show you how to connect Falco to your own ecosystem and how to go further with it with an example of a response engine. I'm Thomas LaBarisias. I'm currently an SRE at Comto, an European New York. And I am a Falco contributor for two years now. Not for the current GIN because I'm not a C++ developer, but with the website, the communication. I'm writing some blog posts and I'm trying to help people on slack about their issues with Falco. I am also the creator of Falco Sidekick, the tool for helping you to use Edge with Falco. Falco currently uses file different outputs, GRPC. We provide ClientLibrary, Mingo and Python. File, STD Out, which is commonly used by FileBeat, 3ND or other log collectors in Kubernetes. Shell for sending full pipe your events to the program you want. And HTTP is basically a webbook with the event as output. Falco Sidekick uses this last one because it's an HTTP proxy waiting for an event from Falco in JSON format. So the idea behind all your Falco instances. I remember you that Falco is a demand set. So you have one Falco by node in your cluster. All your Falco push their events to Falco Sidekick, which is a deployment, not an event set, not a cycle. And Falco Sidekick exposes primitives and points for metrics. It's convenient because this is a central point for all events from all Falco. Then Falco Sidekick pushes this event in a fan out mode to all outputs you have set. You can even filter the destination by priority. For example, you want to record all events in an elastic search as logs, but only notify your own call utility team for priorities above critical. It's possible. Another useful feature of Falco Sidekick is the possibility to add custom fields to events like the region or data center. With a large number of available outputs and more and more are added by the community each month, thanks to everybody. You can really connect Falco to your current ecosystem and easily take advantages from it. For now, we have around 30 different output chat services, Slack, Mattermost, Rockchat, Chat, Discord teams. Sorry. And we have log systems, lucky, elastic search, dot watch logs, queue or streaming systems like NATS, Azure Hub, Kafka, Amazon SQS, Fast, Cubeless, OpenFast, Amazon Lambda, Genitive, Metrics with Prometheus. I've already told you that you can also have Metrics that can send to IntlixDB or Datalog. And for alerting, we have a lot manager from Prometheus, but we have also PajeroDuty and OpsG, and we are currently integrating VictorHops. You can do more with SMTP or email, etc. So with Falco, we can detect threats, with Falco Sidekick, threats or at least bad behaviors. With Falco Sidekicks, we are able to get notifications, but we can do more with some of the outputs I've just mentioned to you. So we've functioned as a service, Amazon Lambda, Cubeless, OpenFast, and Genitive through the CloudEvents integration. You can react to these threats and try to mitigate them as fast as possible. Here for a demo. So imagine this is your website, you're below the website, is running with CMS from the market, whatever which one, and I will emulate a shell running inside. So what happened? Falco has detected a shell has been spawned in your code and sent the event to Falco Sidekick. So Falco Sidekick after sends the event to two different outputs, WebUI and Cubeless. And Cubeless behind is its function called delete pod and the pod has been effectively deleted in less than one second. We can check in the UI. So here we go. We have a message in event. For the whole terminal shell in computer, we have all details, which pod, in which namespace, what image was used somewhere, which command line has been started, which croc has been started in the pod by room, root, etc. We have timelines to, etc, etc. So no, Radica will take you through the Falco website internalization process, really hard world. She will elaborate how Malayalam translation is progressing and helps you get started with translating Falco website to your own language. Thank you. Hi, I'm Radica, a technical writer with SISTIC and with me as a prize guest, Shreeda who contributes to the Malayalam translation effort. As we know, diversity and inclusions are the core principles of the CNCF ecosystem. As its incubation project, Falco aligns and functions in the fullest expression of this principles. As we recognize internationalization as a powerful tool to facilitate openness and participation by breaking language barriers, Falco encourages and stands for internationalization effort. With three projects near completion and one underway, Falco is leading the way. And today we would like to share with you how we do internationalization the Falco way. If you are translation enthusiast and would like to contribute to a cutting edge runtime security project, this is for you. First thing first, before you initiate your translation project, do read our contributor guidelines. It helps you understand about our community, how we function as a community and how we celebrate each other and our achievements. Next thing we would advise you to read is our translation guidelines, which is still underway will be available to you shortly. It should help you to get started with each steps you require to do to do your translation project. Now coming to the GitHub. For the Falco website repository. Don't forget to legarily sync your work with upstream repo. Start with small chunks of conceptually related content. Once it is complete, create the pull request. You can manually assign the language labels in the PR comments. It is a good practice to refer to the other language project as a starting point for your translation. Don't forget to choose your favorite language key part. See if it gels with the market editor that you use. If not, don't worry. Simply use a Google Doc and its language option. Then copy the content over to the market editor and save it. As a first step, identify the language code associated with the language you are trying to translate to coming out to the translation project. There are four directories of files that you want to focus on. First thing is the website content directory where all the language directory reside. For example, here is the Malayalam directory. We have started with the documentation docs directory where allowed getting started and third party and so on have been completed. Make sure that you create a non file which list. Who are the approvers who are the reviewers for your translation project. If you look at the Falco website, there is a general honors files listing all the approvers and reviewers for this Falco website project. Similarly, you should create one for your own translation project. The next thing you must focus on is the internationalization directory where you can see that there is a YAML file. You can see for English, Japanese, Korean, Malayalam and Chinese. For you, you must create one for your language. So if you look at the Malayalam YAML.YAML file, you can see that this is nothing but this is the translate content for the websites homepage. So when you do that, you will have a website homepage in your own language. The next file you should create or you should have a section is the config.toml file. This is the file that all the configuration option for the static generator huger. So make sure that you create a language subsection for your language. For example, you can see for Korean, Chinese and Japanese and see for Malayalam and so on. So make sure that you create a similar subsection for responding to your language. I think I have covered what are the major things you should focus on when you start translating. One point to note down is that when you start translating, make sure that all the directories must have an index.empty file, which is the landing page for that particular topic. For example, the docs directory itself has an index.empty. And when you go inside deep into subdirectories, each one will have an index.empty, which would correspond to the landing page for that particular topic. I think I have covered most of the things I want to cover, except that when you do the PR request, make sure that your description is complete. The type of PR is uncommented and explained to the reviewers what you are trying to achieve. For example, what this PR for and for example here, Shridha's PR which says it's for alert documentation and it's translate alerts and third party sections within the Getting Started directory. And if you're thinking what you have to start with, start with the Getting Started section, that is the first document anyone who is new to Falco should start reading. So when you start your translation project, start with the Getting Started documentation. So with that said, I will give it to Shridha and let's see what she has to talk about her experience working for contributing to Falco. Shridha, over to you. Hi, I am Shridha, an intern for the Falco Internationalization Project. I work on the Malayalam translation. I'm from India and I'm a postgraduate in mass communication. It has been a great experience working with the talented bunch of contributors and learning about open source community, the internationalization process and all the nuances of open source software development. Falco is looking for contributors and we have a great team. It's a great platform for beginners to get exposure and learn by contributing. I encourage you to come and join us. Thank you. And Shridha, we are looking for contributors and if you have any questions about internationalization, do reach out to us and let's grab a coffee and let's talk about translation. Thank you.