Jun 20th, 2019 - Meeting minutes

meeting-notes/2019-Jun-06.md

@@ -1,4 +1,4 @@
-# Falco Office hours meeting 6th June 2019
+# Falco Office hours - Meeting 6th June 2019
 
 **MC:** Lorenzo Fontana
 
@@ -19,28 +19,29 @@ and there have been 7 people participating very actively.
 
 ## Proposals
 
-[#5](https://github.com/falcosecurity/office-hours/issues/5): Improved Falco outputs
+[office-hours#5](https://github.com/falcosecurity/office-hours/issues/5): Improved Falco outputs.
 
-Thomas Labarussias presented it as proposed in the issue, slightly different than what was proposed initially on having a grpc output.
+Thomas Labarussias ([@issif](https://github.com/issif)) presented it as proposed in the issue, slightly different than what was proposed initially on having a gRPC output.
 
-- **Ducy:** thinks that it should be only a grpc plugin and not a sidekick 
-- **Leo**: Also if I'd like to have fan-in/out mechanisms and broadcasting of events, I think the architecture is a bit overkill, for example I have concerns about all the queues in the diagram and the different mechanisms used to grab data from them (push vs pull)
-- Mark and Kaizhe think that the architecture is a bit giant, needs to be simpler
+- **Ducy**: Ducy thinks that it should be only a gRPC plugin and not a sidekick.
+- **Leonardo**: Also if I'd like to have fan-in/out mechanisms and broadcasting of events, I think the architecture is a bit overkill, for example I have concerns about all the queues in the diagram and the different mechanisms used to grab data from them (push vs pull)
+- Mark and Kaizhe think that the architecture is a bit giant, needs to be simpler.
 - **Kaizhe Question**: when I look into the diagram I can't understand what Falco is expected to provide, auditing events or what? It's not that crazy now, trying to reduce noise, what do you expect from Falco regarding events?
 - **Thomas Answer**: I just want a very simple configuration on which plugins are enabled and what events are received, if you take my program - ie., issif/falcosidekick - I didn't integrate the idea of minimum criticality, it's only that, which plugin are enabled and what events. No rules on which kind of messages etc. Falco has to be the truth, the knowledge base.
 - **Kaizhe**: I'm more looking into this to enrich how this new architecture can bring the detection capabilities to the next level, I see some flexibility here when we have a broker and it can't be easily to enrich the Falco events but I think I still agree with Mark, maybe start with simple and see what we can do from there.
-- **Thomas**: It's a little bit complicated to have a mechanism that will work everywhere
+- **Thomas**: It's a little bit complicated to have a mechanism that will work everywhere.
 - **Mattia**: I don't have a complete understanding and view on this problem, just started to learn Falco last week.
 
-[#6](https://github.com/falcosecurity/office-hours/issues/6): Github and contribution automation:
+[office-hours#6](https://github.com/falcosecurity/office-hours/issues/6):
+Github and contribution automation.
 
-- **Leonardo**: we have an idea to improve the way internal and external contribute to falco, this idea is to implement and automate a lot the workflow, to make everything more structured in a way that in every moment we have statistics about the number of issues, the kind of issues, the area the issue refers to, and a set of commands, and a set of well defined rules so that for example no one can just merge their PR without following the rules. 
+- **Leonardo**: we have an idea to improve the way internal and external contribute to falco, this idea is to implement and automate a lot the workflow, to make everything more structured in a way that in every moment we have statistics about the number of issues, the kind of issues, the area the issue refers to, and a set of commands, and a set of well defined rules so that for example no one can just merge their PR without following the rules.
 The first phase is to apply this set of rules only on issues and PRs, next we will automate things like: the kind of git history we want to enforce, allowing or disallowing merge commits for the PR; implement branch protection, let’s say that we use a git flow model with feature/*, hotfix/*, master and develop branches and we want to disallow pushing against master. The tool we are experimenting with is Prow, the same tool that every CNCF project like k8s, knative, istio, prometheus, jetstack, azure k8s engine, and some other use. We can use it for all the repository in the Falco organization since it’s multi-tenant. The setup is already visible in https://github.com/falcosecurity/test-infra you can find all the yaml engineering needed there (https://yaml.engineering lulz).  We have deployed it on an EKS Kubernetes. We have a config file and a plugin file, the config file is used to define the general configuration about the plugins. We have PR sizes, reviewer auto assign, approve and looks-good-to-me chatops, among the others. Cannot explain in detail every plugin here. But I hope the general sense of such automation has been given.
 Also I want to say that in a third phase with such tool we could implement also Continuous Integration based on Kubernetes.
 - **Lorenzo**: Leo, can you show some PRs or issues automated with it?
 - **Leonardo**: Yes, and he showed closes PR on test-infra with initial automation in place, OWNERS with automatic approvers and reviewers mechanism, TIDE tool for automatic and periodic merging of PR respecting all of the conditions required to be merged, etc.
-- **Mattia**: it could be a good way to improve the workflow of the falco development and can be helpful to manage and optimize the management of the software engineering branch of falco so I guess that if there is a big project such as falco a tool like this can be very helpful.
+- **Mattia**: It could be a good way to improve the workflow of the falco development and can be helpful to manage and optimize the management of the software engineering branch of falco so I guess that if there is a big project such as falco a tool like this can be very helpful.
 - **Michael**: I like it, gonna help with a lot of the challenges we have, the more we can make this automated the easier it will be.
 - **Thomas**: I didn't  follow the discussion sorry, but in general seems good to me.
-- **Kaizhe**: looks good to me, I like it, makes the project more structured.
-- **Spencer**: no strong opinion.
+- **Kaizhe**: Looks good to me, I like it, makes the project more structured.
+- **Spencer**: No strong opinion.

meeting-notes/2019-Jun-13.md

@@ -1,6 +1,6 @@
-# Falco Office Hours meeting 13th June 2019
+# Falco Office Hours - Meeting 13th June 2019
 
-**MC:** Michael Ducy (@mfdii)
+**MC:** Michael Ducy
 
 **Who joined**
 
@@ -17,17 +17,19 @@
 
 ## Proposals
 
-[#10](https://github.com/falcosecurity/office-hours/issues/10)
-Discuss Falco Images and how they are built
-- **Jean:** create a mini container as a helper to build the kernel module and drop the kernel module. Later on the main container pick up the kernel module via mount. The downside is for k8s/openshift only. Mini-ubuntu is down the load can be used. Having a different dev and stable docker image might not be a good idea. Should be combined ? Support Ubuntu 14.04 ? I can do the code review for PoC. 
-- **Mark:** Use insmod. The init container do the load and the main container did the unload.  Has a plan to shrink the image to build into alpine image. Dev and Stable dockerfile can be combined. Mark will do that. Keep the old compiled version for redhat. Sysdig people can do it.
-- **Ducy:** Multi-stage dockerfile. A build container will generate the RPM and then docker pick up the RPM file. The dockerfile doesn’t compile Falco at the moment. In the run stage, just copy the build result that can be used.  Redhat6 is something to support. Using init container to build kernel module is repeatable. 
-- **Topic:** Vulnerabilities Management in Image
-- **Mark:** the number is high, need some expertise to remove them
-- **Jean:** Upgrade version should remove a lot of them.
+[office-hours#10](https://github.com/falcosecurity/office-hours/issues/10):
+Discuss Falco Images and how they are built.
 
+- **Jean**: create a mini container as a helper to build the kernel module and drop the kernel module. Later on the main container pick up the kernel module via mount. The downside is for k8s/openshift only. Mini-ubuntu is down the load can be used. Having a different dev and stable docker image might not be a good idea. Should be combined ? Support Ubuntu 14.04 ? I can do the code review for PoC.
+- **Mark**: Use insmod. The init container do the load and the main container did the unload.  Has a plan to shrink the image to build into alpine image. Dev and Stable dockerfile can be combined. Mark will do that. Keep the old compiled version for redhat. Sysdig people can do it.
+- **Ducy**: Multi-stage dockerfile. A build container will generate the RPM and then docker pick up the RPM file. The dockerfile doesn’t compile Falco at the moment. In the run stage, just copy the build result that can be used.  Redhat6 is something to support. Using init container to build kernel module is repeatable.
+- **Topic**: Vulnerabilities Management in Image
+- **Mark**: the number is high, need some expertise to remove them
+- **Jean**: Upgrade version should remove a lot of them.
 
-Issues with EC2 and Systemd Unit File needed
-- **Jean:** Using a lot of CPU in EC2 instances, it was bad. Also saw crashes multiple times. Need to address that issue if we want to deploy falco in production. With Ansible the systemd trigger the reload. I don’t know how it build. It is sort of critical. No log for falco crash. The falco log into syslog. There is nothing interesting there. It runs for a few hours and then crash. We need to do apt-get update before upgrade another version of falco. Right now we don’t do apt-update. We setup the repo, but after that we never call apt-get update. We should not use puppet to do upgrade. We simply push new AMI to upgrade falco. User Management binary rule get triggered a lot.
-- **Ducy:** Walk me through this. Drop it in the puppet code. It is built via cmake. Any log for the falco crash? Regarding FP, kaizhe is the person to contact. 
-- **Kaizhe:** Let’s spend time to go through JP’s scenario to make some rules for his particular environment. Looks puppet generate a lot of noise there.
+
+Issues with EC2 and Systemd Unit File needed.
+
+- **Jean**: Using a lot of CPU in EC2 instances, it was bad. Also saw crashes multiple times. Need to address that issue if we want to deploy falco in production. With Ansible the systemd trigger the reload. I don’t know how it build. It is sort of critical. No log for falco crash. The falco log into syslog. There is nothing interesting there. It runs for a few hours and then crash. We need to do apt-get update before upgrade another version of falco. Right now we don’t do apt-update. We setup the repo, but after that we never call apt-get update. We should not use puppet to do upgrade. We simply push new AMI to upgrade falco. User Management binary rule get triggered a lot.
+- **Ducy**: Walk me through this. Drop it in the puppet code. It is built via cmake. Any log for the falco crash? Regarding FP, kaizhe is the person to contact.
+- **Kaizhe**: Let’s spend time to go through JP’s scenario to make some rules for his particular environment. Looks puppet generate a lot of noise there.

meeting-notes/2019-Jun-20.md

@@ -0,0 +1,80 @@
+# Falco Office hours - Meeting 6th June 2020
+
+**MC:** Leonardo Di Donato
+
+**Who joined**:
+
+- Leonardo Di Donato ([@leodido](https://github.com/leodido))
+- Lorenzo Fontana ([@fntlnz](https://github.com/fntlnz))
+- Mark Stemm ([@mstemm](https://github.com/mstemm))
+- Kaizhe Huang ([@kaizhe](https://github.com/kaizhe))
+- Knox Anderson ([@knoxanderson](https://github.com/KnoxAnderson))
+- Arístides González ([@ariguillegp](https://github.com/ariguillegp))
+
+This was the third official Office Hours meeting!
+
+## Proposals
+
+**Leonardo**: Not a lot of proposals in the office hours repo this week, but there's a thing I proposed days ago, you can find it in the office hours issues list, issue number #9.
+
+[office-hours#9](https://github.com/falcosecurity/office-hours/issues/9):
+Declarative management of org settings, teams, and memberships.
+
+
+- **Leonardo**: I'd like to automate organizations settings, teams and memberships too. Similarly to what made on labels/PR workflows side. There is a tool, [peribolos](https://github.com/kubernetes/test-infra/blob/master/prow/cmd/peribolos/README.md), that other cloud native projects (like Kubernetes) are already using.
+This tool allows to define the teams, privileges of the people in a declarative way. It works with Prow. This is something in my opinion we need to do to reorganize all the roles we have in the organization and having them publicly managed and visible.
+Leonardo asks people to contribute thoughts or concerns about the matter.
+- **Mark**: I'm not so sure we are at that kind of scale yet but it's ok.
+- **Lorenzo**: I've been noticing that a lot of the automation things we've being doing have made repos better. Imho machine users should do these kind of tasks, not human users manually. Also because human users are very error-prone. So to me it'll be useful. Also such thing improves the transparency level of falco organization.
+- **Leonardo**: Exactly, this is what I personally care most of. I'm glad you caught it. In this way we we'll need to add someone to the repo, give him write privileges, there will be a public PR and everyone can see why we are adding it or not, what's the goal. It's all tracked down and transparent. There are not things happening behind the scenes, that people outside cannot understand. They'll look at the PR ...
+- **Knox**: I'll forward to Khaize on this one.
+- **Khaize**: I think this will be very helpful only in a scenario when Falco will have groups of heavy contributors from outside. So maybe it's a little bit early for this?
+- **Leonardo**: Ok, I understand your point. I personally do not think it's too early because the Falco organization already contains other repos with different scenarios and users. I'm thinking to the documentation part in the falco website repository, for example. Other repositories' contributions (and contributors) are going to grow in a different way than Falco ones. And I think we need a way to track down the memberships in public.
+- **Khaize**: Let me ask another question. What's the overhead of this? What's the overhead for existing Falco contributors if you apply this?
+- **Leonardo**: There is no overhead. It's not a huge effort. It's simple a tool that reads a YAML file and call GitHub APIs. Once written only PRs towards it will change it (and consequently) organization settings, memberships, permissions etc.
+- **Lorenzo**: I think that this in reality removes overhead from people. As code changes also this file will have owners. A PR with reviewers will be issued and case by case they will evaluate. But I might be wrong!
+
+
+[falco#673](https://github.com/falcosecurity/falco/pull/673):
+Cmake improvements for building Falco from source on various linux environments.
+
+- **Leonardo**: Ok, I also propose to shift the discussion to the Cmake improvements we are trying to achieve this week, to make Falco easier to build from source on ArchLinux, other linux environments, newer kernels, etc.
+We pushed a PR containing some fixes needed for the most modern environments and so have you guys had a look at this?
+It's not a huge PR. I can show you my screen.
+Basically building Falco from source on newer kernels we (me and @fntlnz) found there were some issues. Namely with libcurl and its flags. And also with flags to make grpc cpp plugin compile. We almost reached the point where it build without troubles .. We need to do some last testing, but ok.
+We also needed this because me and @fntlnz started rewriting and reorganizing the documentation we have on the Falco website about building Falco from source.. [falco-website#28](https://github.com/falcosecurity/falco-website/pull/28) is the ongoing PR. Let's have a look at its preview… I feel this is needed since maybe there are people that want to build Falco from source for developing on it, contribute or just try it, test it locally.
+Leonardo welcomes Aristides.
+- **Aristides**: Thank you thank you very much!
+- **Mark**: The Cmake PR changes are all fine to me.
+- **Lorenzo**: That's want we wanted to know!
+- **Makr**: You know, that kind of stuff is very welcome!
+- **Knox**: No suggestions yet since I hadn't reviewed it yet.
+- **Khaize**: It's ok. Looks cute to me.
+- **Leonardo**: Do you want to present yourself? Propose something or say something about it maybe?
+- **Aristides**: I read the Falco documentation recently and I was wondering why it does not include Alpine Linux. Is because of the C libraries?
+- **Lorenzo**: No is because we didn't think about it yet! Could you open an issue about it?
+- **Leonardo**: Thanks for pointing it out. Yes please open an issue to remind it to us!
+- **Khaize**: Guys I have a question. Who has tested all this instructions and environments we have in the documentation?
+- **Lorenzo**: We tested in all the written down environments. Was kind of hard … We also proposed a change to Sysdig but last minute we noticed that change would requires a compile time directive to have it working everywhere (and we are going to do it soon, maybe through a autotools and/or a pre-directive that populates a Cmake variable). We then made changes to the Cmake files according to this.
+But yeah, building on all those environments have been tested. Of course we did not tried every possible Ubuntu, or Fedora etc.
+- **Leonardo**: The PR that Lorenzo is talking about is [sysdig#1441](https://github.com/draios/sysdig/pull/1441)
+- **Lorenzo**: I'd like to highlight that Mark has made 2 releases this week!
+
+[changelog 0.15.3](https://github.com/falcosecurity/falco/blob/master/CHANGELOG.md#v0153),
+[changelog 0.15.2](https://github.com/falcosecurity/falco/blob/master/CHANGELOG.md#v0152):
+Recap about the patch releases made in the last week.
+
+
+- **Lorenzo**: So we had a bug in compiling for older kernels and that have been fixed in Sysdig. There was also a bug in compiling for Container Optimised OS (GKE).
+The other thing is that a lot of people are opening issues about dropped events. We are trying to understand why this happen and if anyone has insights about it ...
+- **Mark**: I think the kind of things with drops have been incurring all of the time but now it's just more visible because of the alerts. I'm really hoping for the performances optimizations …
+I'd encourage people reporting to report more information about the environments they are using, so we can also understand if they are using at least Falco version 0.15.1.
+- **Lorenzo**: We now have an issue templates that's very clear about it!
+- **Mark**: And in the new reporting issues that were reported the people are using the template?
+- **Lorenzo**: Yes!
+- **Leonardo**: Yep, but there are older issues (like falco#615) before the template were we still do not have info about the environments, but we asked for them ...
+Ok, I think it's all. Has anyone other things to bring up attention? Also this third office hours has come to an end. Thank everyone for joining! Bye folks, see you next week!
+
+
+
+