What would you like to be added:
A new CLI tool called falcoctl.
This would be a new repository.
Here is a proof of concept
Why is this needed:
Think of falcoctl as a .go program that is statically linked so that
operators can enjoy Falco
I totally agree. If it's OK for others, I propose to migrate your POC under falcosecurity/falcoctl and move forward. It makes more sense either if we think about #809.
It should be called falconer as it鈥檚 purpose is to tame and control Falco.
Can we name it falconer and pronounce it as falcon E - R in honor of kube C - T - L?
Agree ! 馃 馃 馃
Notes from slack:
1 - How do we install the Kubernetes resources needed for Falco? Do we have a new operator? Do we put this logic in the CLI tool? Do we parse YAML dynamically from local disk or URL? Obviously we need to allow folks to change bits in their specific Falco install (for instance kernel module vs eBPF probe)
2 - What are we going to do with rules/outputs and using those as composable building blocks for Falco? How will we store them? How will we maintain them?
3 - What on earth is going to take responsibility of reconfiguring and restarting the API server. This is a bold task.
4. Vendoring in Go still sucks, this isn't new
5. We shouldn't use init()
Another thought
6. How do we handle `falconer`/`falcoctl` interacting with different versions of Kubernetes?
We could have a flag to specify which version of Kubernetes to use (this might be a dependency nightmare)
Example
falconer --k8s=1.10.8 install falco # Installs this concrete version
falconer --k8s=1.15 install falco # Installs the most recent 1.15.* version
This would allow us some freedom of building in custom logic for each release (relevant to #809) as we push this to GA.
We could branch our code for various versions of Kubernetes, but again, this would be a pain to keep up with. Maybe we could only support Kubernetes LTS?
falcoctl1.14 install falco
falconer-1.13 install falco
alias falconer.k8s.1.12="f"
We could have falcoctl / falconer smart enough to parse the Kubernetes API server version and use the version associated with it.
We also need to think about managed k8s, for example, we can't load kernel module on GKE, eBPF becomes mandatory. Same for auditsink (for k8s events), it's not available in EKS/GKE. If k8s versionning nigthmare is hell, it's still only top of iceberg.
@fntlnz RUNBPF
@kris-nova this feature looks very interesting, I was a bit skeptic about it initially but after looking at your poc code and testing it out I feel like we need it to improve our user experience by far.
RUNBPF contest
Send me an email `lo at linux.com` with your full name and address for the sticker! (I also accept encrypted emails if you have privacy concerns. You can get my public key here https://fntlnz.wtf/downloads/pubkey-0xD624DE73B2400EE4.asc)
Also please review, and manually merge once you are ready @fntlnz
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This was done. We can close this and follow up in the falcoctl repo
/close
@fntlnz: Closing this issue.
In response to this:
This was done. We can close this and follow up in the falcoctl repo
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Most helpful comment
It should be called
falconeras it鈥檚 purpose is to tame and control Falco.