feat(docs): Install support and new blog

config.yaml

@@ -261,7 +261,7 @@ languages:
       #  weight: 5
 
 params:
-  version: v0.20.0
+  version: v0.23.0
   githubRepository : falcosecurity/falco
   sha256sum: 21e8053c37e32f95d91c9393d961af1c63b5839d795c8cac314d05daadea9779
   primaryFont:

content/en/blog/falco-and-kubernetes.md

@@ -0,0 +1,140 @@
+---
+title: We love Kubernetes! Which is why we don't want you to run Falco there.
+description: Understanding our decision to recommend running Falco natively on Linux hosts.
+date: 2020-04-20
+author: Kris Nóva
+---
+
+Since joining [Sysdig, Inc](https://sysdig.com) in August of 2019 I have enjoyed watching The Falco Project grow and gain adoption. 
+
+As the project has grown The Falco Community has been discussing introducing a concept of **official support** given the overwhelming requests for support for various installation methods. 
+
+This new idea would set a clear scope for which artifacts, and avenues the project has agreed to support for the community. 
+The motivation behind this is that we would live to give the community a minimal set of artifacts and installation avenues to support while keeping the project accessible, secure, and resilient. 
+
+{{< success >}}
+
+It is important to understand what we mean by "support" in this context. We are simply defining the artifacts and avenues in which The Falco Project claims responsibility for maintaining. 
+
+Any contributor will always be able to create and document any third-party integration with full endorsement and resources from the community.
+
+{{< /success >}}
+
+So to start, let's look at the goals and constraints of what we would like to achieve for our official installation methods.
+
+## Goals
+
+**Accessible**: A standard Linux user should easily be able to get Falco up and running in just a few minutes. 
+This includes understanding Falco, downloading Falco, installing Falco, and demonstrating that it does what it advertises to do. 
+
+**Secure**: Falco at it's core is a security project. 
+In an attempt to lead by example, we have to take all security concerns seriously. 
+Falco is a powerful tool, and by nature the project should not endorse running Falco in such a way that it can compromise itself. 
+In short, we don't think Falco should alert against it self. We should see to this not by bypassing the alerts, but rather by truly running Falco in a safe way.
+
+**Resilient**: Falco should be hard to break, and should be there when unexpected things happen.
+Falco should also run at the lowest level of a system, without exposing itself to lateral exploits at the level it's running. 
+In other words, we don't think a last line of defense should be running at the same layer we hope to be protecting. 
+
+## Constraints 
+
+**Minimal set up artifacts**: In an attempt to simplify what The Falco Project is responsible for building, hosting, and documenting we aim to provide a "lowest common ancestor" approach given the goals above. 
+
+**Falco cannot alert against itself**: We cannot treat Falco any different than another application. If given avenue is a risk and is something the community has agreed to support we MUST fix it. 
+
+**5 Minutes or less check**: A reasonably modern Linux user with backend access to a system should be able to install, manage, and observe Falco in 5 minutes or less.
+
+## Official Support - Falco on Linux with Systemd
+
+So after a few months of deliberation in the [Falco community](https://github.com/falco/community) we have decided to only support (and strongly encourage) Falco running on the host system in a Cloud Native environment. 
+
+This means that The Falco Community will only support installations where Falco is running on the underlying host and was installed using one of the supported Linux packages.
+
+ - Debian/Ubuntu (`.deb` packages)
+ - RHEL/EC2 Linux/CentOS (`.rpm` packages)
+ - Binary installation (`.tar.gz` packages)
+
+[Read more](https://falco.org/docs/installation) in the documentation.
+
+Furthermore we will support a handful of container images as a community. These images will only contain the userspace component of the Falco process, and will still require a driver installed on the underlying host to work. 
+
+As a project we will encourage installation using the packages above, and deployment via `systemd` or `init` on older systems. 
+We will support running the userspace component in a container, and users can install a driver as they prefer. 
+
+
+## The Kubernetes Story 
+
+We understand that most Cloud Native end-users run their applications in Kubernetes. This is the main reason we suggest for Falco NOT to run in Kubernetes. 
+
+{{< info >}}
+
+**Where should I run Falco then**?  
+
+The main work horse behind Kubernetes is called the Kubelet and is installed using a `systemd` unit file.
+We hope to mirror that same functionality with Falco. 
+
+{{< /info >}} 
+
+Lateral movement is a well known attack vector and given the complexity of Kubernetes we suggest that Falco should run **beside** Kubernetes, instead of **on top** of Kubernetes. 
+In the event that an application or cluster is compromised having a set of checks and balances running at a different level of the stack provides resilience against these zero day situations. 
+
+We hope that administrators see the wisdom in running Falco as a `systemd` unit. Falco offers an easy to use gRPC API where a Kubernetes pod could safely consume Falco events and shuttle them around the rest of the cluster as needed. 
+
+## Reviewing our Installation methods
+
+As we began exploring deployment and installation avenues we started to look at things such as the Falco static manifests, the `helm` chart, and even the complexity of the container images we built. 
+
+We started to notice that all of these installation methods involved a large amount of complexity when it came time to ensure a driver was installed. Why? 
+Because by design Kubernetes has limited or no access to the layer of the stack that we need to gain access to in order to set up the driver, the kernel. 
+
+So while in some cases we were able to "work around" this limitation, these "work arounds" weren't a viable long term solution. In the case of the `helm` chart and the static manifests we blatantly exploited a well known vector in Kubernetes such that Falco would alert against itself upon installation.
+
+As a security tool, this was concerning.
+As an engineering org, this was a red flag that we were trying to do something we shouldn't be doing. 
+As a project, this was causing a lot of confusion. 
+
+We hope that users will understand that having Falco running in the system it is supposed to be watching, fundamentally doesn't make very much sense.
+
+{{< info >}}
+
+**Will Falco still work with Kubernetes**?  
+
+Absolutely. 
+
+Falco by design is built to work with Kubernetes. 
+It will continue to consume Kubernetes events, and alert against Kubernetes anomalies in the exact same way it always has. 
+
+{{< /info >}} 
+
+{{< info >}}
+
+**What if this impacts my deployment of Falco**?  
+
+Remember nothing in the existing Falco ecosystem will change other than our documentation around what is and isn't an officially supported installation method. 
+If you are still impacted by this and were unable to be apart of the planning sessions please reach out to the [Falco mailing list](https://lists.cncf.io/g/cncf-falco-dev) so we can immediately look at your concern. 
+
+
+{{< /info >}} 
+
+
+## Third Party Integrations
+
+There are many open source projects that Falco has integrated with such as `helm`, `minikube`, `kubernetes`, `prometheus`, and even configuration management systems such as `puppet`, `chef`, and `ansible`. 
+
+The Falco Community will have a space to document these integrations, and will provide a space for the community to work and build out these integrations in a safe, and productive way.
+
+We will characterize them as third-party integrations, and will keep them separated from the small scope of the supported artifacts mentioned above so that they can grow as needed. 
+
+Furthermore we hope to start offering a "Falco Install" container that will use the privilege escalation method defined earlier to simply install Falco on the host, and exit so that users who are bound by the Kubernetes API can still get Falco installed.
+
+
+{{< info >}}
+
+**Will Falco still work with my cloud provider**?  
+
+Yes.
+
+There will be many options for running Falco in various cloud providers, and as a community we will be working on tooling to make this a seamless experience while still adhering to our constraints. 
+
+{{< /info >}} 
+

content/en/docs/_index.md

@@ -1,42 +1,92 @@
 ---
-title: Documentation Home
-description: An overview of the Falco container security system
+title: The Falco Project
+description: Cloud Native Runtime Security
 weight: 1
 ---
 
-## About Falco
+{{< info >}}
 
-Falco is a behavioral activity monitor designed to detect anomalous activity in your applications. Using powerful [system call capture](https://sysdig.com/blog/fascinating-world-linux-system-calls/) technology originally built by Sysdig. Falco lets you continuously monitor and detect container, application, host, and network activity, all in one place, from one source of data, with one set of [rules](rules).
+The Falco Project does not suggest running Falco on top of Kubernetes but rather beside Kubernetes on the Linux host with systemd. 
 
-### What kind of behaviors can Falco detect?
+See this [blog post](https://falco.org/blog/falco-and-kubernetes/) for more information.
 
-Falco can detect and alert on any behavior that involves making [Linux system calls](http://man7.org/linux/man-pages/man2/syscalls.2.html). Falco alerts can be triggered by the use of specific system calls, their arguments, and by properties of the calling process. For example, you can easily detect when:
+{{< /info >}}
 
-* A shell is run inside a container
-* A server process spawns a child process of an unexpected type
-* A sensitive file, like `/etc/shadow`, is unexpectedly read
-* A non-device file is written to `/dev`
-* A standard system binary (like `ls`) makes an outbound network connection
+## What is Falco?
 
-## How Falco compares to other tools
+The Falco Project is an open source runtime security tool originally built by [Sysdig, Inc](https://sysdig.com). Falco was [donated to the CNCF and is now a CNCF incubating project](https://www.cncf.io/blog/2020/01/08/toc-votes-to-move-falco-into-cncf-incubator/).
 
-People often ask how Falco differs from [SELinux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux), [AppArmor](https://wiki.ubuntu.com/AppArmor), [Auditd](https://linux.die.net/man/8/auditd), and other tools related to Linux security policy. We wrote a [blog post](https://sysdig.com/blog/selinux-seccomp-falco-technical-discussion/) on the [Sysdig blog](https://sysdig.com/blog) comparing Falco to other tools.
+## What does Falco do?
 
-## How to use Falco
+Falco parses Linux system calls from the kernel at runtime, and asserts the stream against a powerful rules engine. 
+If a rule is violated a Falco alert is triggered. Read more about Falco [rules](rules)
 
-Falco is deployed as a long-running daemon. You can install it as a [deb](installation#debian)/[rpm](installation#centos-rhel) package on a regular host or container host, you can deploy it as a [container](installation#docker), or you can build it [from source](source).
+ - Parse
+ - Assert
+ - Alert
 
-Falco is configured via (1) a [rules file](rules) that defines which behaviors and events to watch for and (2) a [general configuration file](configuration). Rules are expressed in a high-level, human-readable language. We've provided a sample rules file [`./rules/falco_rules.yaml`](https://github.com/falcosecurity/falco/blob/master/rules/falco_rules.yaml) as a starting point—you can (and will likely want!) to adapt it to your environment.
+## What does Falco look for?
 
-When developing rules, one helpful feature is Falco's ability to read trace files saved by the `scap` format. This allows you to "record" the offending behavior once and replay it with Falco as many times as needed while tweaking your rules.
+By default Falco ships with a mature set of rules that will check the kernel for unusual behavior such as
 
-Once deployed, Falco uses the kernel modules and eBPF probes to bring events to userspace. Falco watches for any events matching one of the conditions defined in the rule file. If a matching event occurs, a notification is written to the the configured output(s).
+ - Privilege escalation using privileged containers 
+ - Namespace changes using tools like `setns` 
+ - Read/Writes to well-known directories such as `/etc`, `/usr/bin`, `/usr/sbin`, etc
+ - Creating symlinks 
+ - Ownership and Mode changes 
+ - Unexpected network connections or socket mutations
+ - Spawned processes using `execve`
+ - Executing shell binaries such as `sh`, `bash`, `csh`, `zsh`, etc
+ - Executing SSH binaries such as `ssh`, `scp`, `sftp`, etc
+ - Mutating Linux `coreutils` executables
+ - Mutating login binaries 
+ - Mutating `shadowutil` or `passwd` executables 
+    - `shadowconfig`
+    - `pwck`
+    - `chpasswd`
+    - `getpasswd`
+    - `change`
+    - `useradd`
+    - etc
 
-## Falco alerts
+...and many more. 
 
-When Falco detects suspicious behavior, it sends [alerts](alerts) via one or more channels:
+## What are Falco rules?
 
-* Writing to standard error
-* Writing to a file
-* Writing to syslog
-* Pipe to a spawned program. A common use of this output type would be to send an email for every Falco notification.
+These are the items that Falco will assert against. They are defined in the Falco configuration, and represent the things you will be looking for on your system.
+
+See the section on [rules](rules) for more information on writing, managing, and deploying Falco rules.
+
+## What are Falco alerts?
+
+These are configurable downstream actions that can be as simple as logging to `STDOUT` or as complex as delivering a gRPC call to a client. 
+
+See the section on [alerts](alerts) for more information on configuring, understanding, and developing Falco alerts.
+
+
+## Falco Components 
+
+Falco is composed of 3 main components
+
+ - Userspace program
+ - Driver
+ - Configuration
+
+### Falco userspace program
+
+This is the CLI tool `falco`. This is the program a user interacts with. The userspace program is responsible for handling signals, parsing information from a Falco driver, and alerting.
+
+### Falco driver
+
+This is a piece of software that adheres to the Falco driver spec and can send a stream of system call information from the kernel.
+Falco cannot run without a driver installed.
+
+Currently the Falco project has support for the following drivers
+
+ - (Default) A kernel module built on `libscap` and `libsinsp` C++ libraries
+ - A BPF probe built from the same modules
+ - A new BPF probe being built out by the Falco community 
+
+### Falco configuration 
+
+This defines how Falco is run, what rules to assert, and how to perform alerts. See the section on [configuration](configuration) for more information on how to configure Falco. 

content/en/docs/configuration.md

@@ -1,13 +1,27 @@
 ---
-title: Falco Configuration
+title: Configuration
+description: Configuration for the Falco daemon
 weight: 5
 notoc: true
 ---
 
+{{< info >}}
+
+This is for the Falco daemon configuration options.
+
+Please visit [rules](../rules) or [alerts](../alerts) for those options.
+
+{{< /info >}}
+
+
 Falco's configuration file is a [YAML](http://www.yaml.org/start.html) file containing a collection of `key: value` or `key: [value list]` pairs.
 
+
+
 Any configuration option can be overridden on the command line via the `-o/--option key=value` flag. For `key: [value list]` options, you can specify individual list items using `--option key.subkey=value`.
 
 ## Current configuration options
 
+
+[comment]: <> (@kris-nova: This data is loaded from the YAML file in data/en/config.yaml)
 {{< config >}}

content/en/docs/download.md

@@ -0,0 +1,58 @@
+---
+title: Download
+description: Officially supported Falco artifacts
+weight: 2
+---
+
+## Downloading
+
+The Falco Project community only supports two ways for downloading and running Falco:
+
+ - Running Falco directly on a Linux host
+ - Running the Falco userspace program in a container, with a driver installed on the underlying host.
+
+Below you can find artifacts for both. 
+
+
+### Download for Linux {#packages}
+
+|        | development                                                                                                                 | stable                                                                                                              |
+|--------|-----------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------|
+| rpm    | [![rpm-dev](https://img.shields.io/bintray/v/falcosecurity/rpm-dev/falco?label=Falco&color=%2300aec7&style=flat-square)][1] | [![rpm](https://img.shields.io/bintray/v/falcosecurity/rpm/falco?label=Falco&color=%23005763&style=flat-square)][2] |
+| deb    | [![deb-dev](https://img.shields.io/bintray/v/falcosecurity/deb-dev/falco?label=Falco&color=%2300aec7&style=flat-square)][3] | [![deb](https://img.shields.io/bintray/v/falcosecurity/deb/falco?label=Falco&color=%23005763&style=flat-square)][4] |
+| binary | [![bin-dev](https://img.shields.io/bintray/v/falcosecurity/bin-dev/falco?label=Falco&color=%2300aec7&style=flat-square)][5] | [![bin](https://img.shields.io/bintray/v/falcosecurity/bin/falco?label=Falco&color=%23005763&style=flat-square)][6] |
+
+The list of all available artifacts can be found [here](https://bintray.com/falcosecurity).
+
+---
+
+### Download container images {#images}
+
+{{< info >}}
+
+Falco depends on having a driver installed on the host system to get information about the running system calls.
+
+The preferred installation method is to install the driver using the native artifacts defined above or 
+temporarily run the `falcosecurity/falco-driver-loader` image as privileged, then using the `falcosecurity/falco-no-driver`.
+
+For more details, see the [Run within Docker section](/docs/running#docker).
+
+{{< /info >}}
+
+|tag | pull command | description |
+|----|----------|-----------------|
+|[latest](https://hub.docker.com/r/falcosecurity/falco-no-driver/tags)| `docker pull falcosecurity/falco-no-driver:latest` | The most recent version |
+|[*version*](https://hub.docker.com/r/falcosecurity/falco-no-driver/tags)| `docker pull falcosecurity/falco-no-driver:<version>` | A specific version of Falco such as `{{< latest >}}` |
+|[latest](https://hub.docker.com/r/falcosecurity/falco-driver-loader/tags)| `docker pull falcosecurity/falco-driver-loader:latest` | The most recent version of `falco-script-loader` with the building toolchain |
+|[*version*](https://hub.docker.com/r/falcosecurity/falco-driver-loader/tags)| `docker pull falcosecurity/falco-driver-loader:<version>` | A specific version of `falco-driver-loader` such as `{{< latest >}}` with the building toolchain |
+|[latest](https://hub.docker.com/r/falcosecurity/falco/tags)| `docker pull falcosecurity/falco:latest` | The most recent version with the `falco-script-loader` included |
+|[*version*](https://hub.docker.com/r/falcosecurity/falco/tags)| `docker pull falcosecurity/falco:<version>` | A specific version of Falco such as `{{< latest >}}` with `falco-script-loader` included |
+
+The list of all available images can be found [here](https://github.com/falcosecurity/falco/tree/master/docker).
+
+[1]: https://dl.bintray.com/falcosecurity/rpm-dev
+[2]: https://dl.bintray.com/falcosecurity/rpm
+[3]: https://dl.bintray.com/falcosecurity/deb-dev/stable
+[4]: https://dl.bintray.com/falcosecurity/deb/stable
+[5]: https://dl.bintray.com/falcosecurity/bin-dev/x86_64
+[6]: https://dl.bintray.com/falcosecurity/bin/x86_64