update(docs): refer to terms in the glossary

Signed-off-by: Vicente J. Jiménez Miras <vjjmiras@gmail.com>

content/en/docs/event-sources/kernel/_index.md

@@ -7,7 +7,7 @@ aliases:
   - /docs/event-sources/drivers
 ---
 
-Falco uses different instrumentations to analyze the system workload and pass security events to userspace. We usually refer to these instrumentations as **syscall sources** since the generated events are strictly related to the syscall context.
+Falco uses different instrumentations to analyze the system workload and pass security events to {{< glossary_tooltip text="userspace" term_id="user-space" >}}. We usually refer to these instrumentations as **syscall sources** since the generated events are strictly related to the {{< glossary_tooltip text="syscall" term_id="syscalls" >}} context.
 
 There are several supported syscall sources:
 
@@ -22,7 +22,7 @@ There are several supported syscall sources:
 
 ## Kernel module
 
-By default, the kernel module will be installed when installing the Falco [debian/rpm](/docs/getting-started/installation) package, when running the `falco-driver-loader` script shipped within the [binary package](/docs/getting-started/installation#linux-binary), or when running the `falcosecurity/falco-driver-loader` docker image (that just wraps the aforementioned script).
+By default, the {{< glossary_tooltip text="kernel module" term_id="kernel-module" >}} will be installed when installing the Falco [debian/rpm](/docs/getting-started/installation) package, when running the `falco-driver-loader` script shipped within the [binary package](/docs/getting-started/installation#linux-binary), or when running the `falcosecurity/falco-driver-loader` docker image (that just wraps the aforementioned script).
 
 To install the kernel module, please refer to the [installation](/docs/getting-started/installation/#install-driver) page.
 
@@ -32,7 +32,7 @@ The kernel module requires full privileges and cannot run with Linux capabilitie
 
 ## Classic eBPF probe
 
-The classic eBPF probe is an alternative source to the one described above.
+The classic {{< glossary_tooltip text="eBPF probe" term_id="ebpf-probe" >}} is an alternative source to the one described above.
 
 To install the eBPF probe, please refer to the [installation](/docs/getting-started/installation/#install-driver) page.
 
@@ -75,7 +75,7 @@ The conditions to satisfy are the following:
 
 ## Modern eBPF probe
 
-The modern probe is an alternative driver for Falco. The main advantage it brings to the table is that it is embedded into Falco, which means that you don't have to download or build anything, if your kernel is recent enough Falco will automatically inject it!
+The {{< glossary_tooltip text="modern probe" term_id="modern-ebpf-probe" >}} is an alternative driver for Falco. The main advantage it brings to the table is that it is embedded into Falco, which means that you don't have to download or build anything, if your kernel is recent enough Falco will automatically inject it!
 
 ### What's new
 

content/en/docs/event-sources/kernel/dropped-events.md

@@ -6,13 +6,13 @@ weight: 60
 ---
 ## Introduction
 
-With the enhancements introduced in v0.15.0, Falco can now intelligently detect dropped system call events and take remedial actions, such as alerting or even exiting Falco entirely. When system call events are dropped, Falco might encounter problems building its internal view of the processes, files, containers, and orchestrator metadata in use, which in turn might affect the rules that depend on that metadata. The explicit signals that Falco now provides make it easier to detect dropped system calls.
+With the enhancements introduced in v0.15.0, Falco can now intelligently detect dropped {{< glossary_tooltip text="system call" term_id="syscalls" >}} events and take remedial actions, such as alerting or even exiting Falco entirely. When system call events are dropped, Falco might encounter problems building its internal view of the processes, files, containers, and orchestrator metadata in use, which in turn might affect the rules that depend on that metadata. The explicit signals that Falco now provides make it easier to detect dropped system calls.
 
 For more information on this feature, see our blog post on [CVE-2019-8339](https://sysdig.com/blog/cve-2019-8339-falco-vulnerability/).
 
 ## Implementation
 
-Every second, Falco reads system call event counts that are populated by the kernel module/eBPF program. The reading includes the number of system calls processed, and most importantly, the number of times the kernel tried to write system call information to the shared buffer between the kernel and user space, but found the buffer was full. These failed write attempts are considered *dropped* system call events.
+Every second, Falco reads system call event counts that are populated by the {{< glossary_tooltip text="kernel module" term_id="kernel-module" >}}/{{< glossary_tooltip text="eBPF" term_id="ebpf" >}} program. The reading includes the number of system calls processed, and most importantly, the number of times the kernel tried to write system call information to the shared buffer between the kernel and user space, but found the buffer was full. These failed write attempts are considered *dropped* system call events.
 
 When at least one dropped event is detected, Falco takes one of the following actions:
 

content/en/docs/event-sources/kernel/sample-events.md

@@ -5,7 +5,7 @@ linktitle: Generating sample events
 weight: 70
 ---
 
-If you'd like to check if Falco is working properly, we have the [`event-generator`](https://github.com/falcosecurity/event-generator) tool that can perform an activity for both our syscall and k8s audit related rules.
+If you'd like to check if Falco is working properly, we have the {{< glossary_tooltip text="event-generator" term_id="event-generator" >}} tool that can perform an activity for both our {{< glossary_tooltip text="syscalls" term_id="syscalls" >}} and {{< glossary_tooltip text="k8s audit" term_id="kubernetes-audit-log" >}} related rules.
 
 The tool provides a command to run either some or all sample events.
 

content/en/docs/event-sources/plugins/kubernetes-audit.md

@@ -5,7 +5,7 @@ linktitle: Kubernetes Audit Events
 weight: 40
 ---
 
-Falco v0.13.0 adds [Kubernetes Audit Events](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/#audit-backends) to the list of supported event sources. This is in addition to the existing support for system call events. An improved implementation of audit events was introduced in Kubernetes v1.11 and it provides a log of requests and responses to [kube-apiserver](https://kubernetes.io/docs/admin/kube-apiserver). Because almost all the cluster management tasks are performed through the API server, the audit log can effectively track the changes made to your cluster.
+Falco v0.13.0 adds [Kubernetes Audit Events](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/#audit-backends) to the list of supported event sources. This is in addition to the existing support for system call events. An improved implementation of audit events was introduced in Kubernetes v1.11 and it provides a log of requests and responses to [kube-apiserver](https://kubernetes.io/docs/admin/kube-apiserver). Because almost all the cluster management tasks are performed through the API server, the {{< glossary_tooltip text="audit log" term_id="kubernetes-audit-log" >}} can effectively track the changes made to your cluster.
 
 Examples of this include:
 

content/en/docs/grpc/_index.md

@@ -5,7 +5,7 @@ description: Enable and configure the gRPC capabilities of Falco
 weight: 70
 ---
 
-Starting from version [0.18.0](https://github.com/falcosecurity/falco/releases/tag/0.18.0), Falco has its own gRPC server which provides a set of gRPC APIs.
+Starting from version [0.18.0](https://github.com/falcosecurity/falco/releases/tag/0.18.0), Falco has its own {{< glossary_tooltip text="gRPC" term_id="grpc" >}} server which provides a set of gRPC APIs.
 
 The current APIs are:
 

content/en/docs/grpc/grpc-config.md

@@ -7,7 +7,7 @@ weight: 10
 
 ## Enabling the Server
 
-The Falco gRPC server and the Falco gRPC Outputs APIs are not enabled by default.
+The Falco {{< glossary_tooltip text="gRPC" term_id="grpc" >}} server and the Falco gRPC Outputs APIs are not enabled by default.
 
 To enable them, edit the `falco.yaml` Falco configuration file. A sample Falco configuration file is given below:
 

content/en/docs/rules/appending.md

@@ -7,11 +7,11 @@ weight: 50
 
 ## Overview
 
-If you use multiple Falco rules files, you might want to append new items to an existing list, macro or rule. To do that, define an item with the same name as an existing item and add an `append: true` attribute to the YAML object. 
+If you use multiple Falco {{< glossary_tooltip text="rules files" term_id="rules-file" >}}, you might want to append new items to an existing {{< glossary_tooltip text="list" term_id="lists" >}}, {{< glossary_tooltip text="macro" term_id="macros" >}} or {{< glossary_tooltip text="rule" term_id="rules" >}}. To do that, define an item with the same name as an existing item and add an `append: true` attribute to the YAML object. 
 
 {{% alert color="warning" %}}
 When appending to lists, items are automatically added to the **end** of the _list_.\
-When appending to rules or macros, the additional content is appended to the _condition_ field of the referred object.
+When appending to rules or macros, the additional content is appended to the {{< glossary_tooltip text="condition" term_id="conditions" >}} field of the referred object.
 {{% /alert %}}
 
 Note that when appending to lists, rules or macros, the order of the rule configuration files matters! For example if you append to an existing default rule (e.g. `Terminal shell in container`), you must ensure your custom configuration file (e.g. `/etc/falco/rules.d/custom-rules.yaml`) is loaded **after** the default configuration file (`/etc/falco/falco_rules.yaml`).

content/en/docs/rules/conditions.md

@@ -5,7 +5,7 @@ linktitle: Condition Syntax
 weight: 40
 ---
 
-A condition is a boolean expression related to a single event that has been detected by Falco. You can use fields related to every supported event, but this document focuses on syscalls as they're currently the most common. The language supports boolean operators and parentheses as you'd expect. For example a condition like:
+A condition is a boolean expression related to a single event that has been {{< glossary_tooltip text="detected" term_id="detection" >}} by Falco. You can use {{< glossary_tooltip text="fields" term_id="fields" >}} related to every supported event, but this document focuses on {{< glossary_tooltip text="syscalls" term_id="syscalls" >}} as they're currently the most common. The language supports boolean operators and parentheses as you'd expect. For example a condition like:
 
 ```
 evt.type = execve and evt.dir = < and (proc.name = cat or proc.name = grep)

content/en/docs/rules/controlling-rules.md

@@ -7,11 +7,11 @@ weight: 80
 
 ## Disable Default Rules
 
-Even though Falco provides a quite powerful default ruleset, you sometimes need to disable some of these default rules since they do not work properly in your environment. Luckily Falco offers you multiple possibilities to do so.
+Even though Falco provides a quite powerful default ruleset, you sometimes need to disable some of these default {{< glossary_tooltip text="rules" term_id="rules" >}} since they do not work properly in your environment. Luckily Falco offers you multiple possibilities to do so.
 
-### Via existing Macros
+### Via existing Macros {#macros}
 
-Most of the default rules offer some kind of `user_*` macros which are already part of the rule conditions. These `user_*` macros are usually set to `(never_true)` or `(always_true)` which basically enables or disables the regarding rule. Now if you want to disable a default rule (e.g. `Read sensitive file trusted after startup`), you just have to override the rule's `user_*` macro (`user_known_read_sensitive_files_activities` in this case) inside your custom Falco configuration.
+Most of the default rules offer some kind of `user_*` {{< glossary_tooltip text="macros" term_id="macros" >}} which are already part of the rule conditions. These `user_*` macros are usually set to `(never_true)` or `(always_true)` which basically enables or disables the regarding rule. Now if you want to disable a default rule (e.g. `Read sensitive file trusted after startup`), you just have to override the rule's `user_*` macro (`user_known_read_sensitive_files_activities` in this case) inside your custom Falco configuration.
 
 Example for your custom Falco configuration (note the `(always_true)` condition):
 ```yaml
@@ -62,7 +62,7 @@ At the same time, disabled rules can be re-enabled by using the `enabled: true`
 
 ## Rule Tags {#tags}
 
-As of 0.6.0, rules have an optional set of _tags_ that are used to categorize the ruleset into groups of related rules. Here's an example:
+As of 0.6.0, rules have an optional set of {{< glossary_tooltip text="tags" term_id="tags" >}} that are used to categorize the ruleset into groups of related rules. Here's an example:
 
 ```yaml
 - rule: File Open by Privileged Container

content/en/docs/rules/default-custom.md

@@ -5,7 +5,7 @@ linktitle: Default and Local Rules
 weight: 20
 ---
 
-Starting with Falco 0.8.0, falco officially supports the notion of a _default_ rules file and a _local_ rules file. This has previously been supported by running falco with multiple `-r` arguments. In 0.8.0, we're formalizing this notion to make it easier to customize falco's behavior but still retain access to rule changes as a part of software upgrades. Of course, you can always customize the set of files you want to read by changing the `rules_file` option in `falco.yaml`.
+Starting with Falco 0.8.0, falco officially supports the notion of a _default_ {{< glossary_tooltip text="rules file" term_id="rules-file" >}} and a _local_ rules file. This has previously been supported by running falco with multiple `-r` arguments. In 0.8.0, we're formalizing this notion to make it easier to customize falco's behavior but still retain access to rule changes as a part of software upgrades. Of course, you can always customize the set of files you want to read by changing the `rules_file` option in `falco.yaml`.
 
 The default rules file is always read first, followed by the local rules file.
 

content/en/docs/rules/exceptions.md

@@ -7,10 +7,7 @@ weight: 70
 
 ## Introduction
 
-Almost all Falco Rules have cases where the behavior detected by the
-rule should be allowed. For example, The rule Write Below Binary Dir
-has exceptions for specific programs that are known to write below
-these directories as a part of software installation/management:
+Almost all Falco Rules have cases where the behavior {{< glossary_tooltip text="detected" term_id="detection" >}} by the {{< glossary_tooltip text="rule" term_id="rules" >}} should be allowed. For example, The rule `Write below binary dir` has exceptions for specific programs that are known to write below these directories as a part of software installation/management:
 
 ```yaml
 - rule: Write below binary dir
@@ -24,7 +21,7 @@ these directories as a part of software installation/management:
     and not user_known_write_below_binary_dir_activities
 ...
 ```
-Previously, these exceptions were expressed as concatenations to the original rule's condition. For example, looking at the macro package_mgmt_procs:
+Previously, these exceptions were expressed as concatenations to the original rule's condition. For example, looking at the {{< glossary_tooltip text="macro" term_id="macros" >}} package_mgmt_procs:
 
 ```yaml
 - macro: package_mgmt_procs
@@ -36,7 +33,7 @@ The result is appending `and not proc.name in (package_mgmt_binaries)` to the co
 A more extreme case of this is the write_below_etc macro used by Write below etc rule. It had tens of exceptions:
 
 ```
-...
+    ...
     and not sed_temporary_file
     and not exe_running_docker_save
     and not ansible_running_python
@@ -47,14 +44,14 @@ A more extreme case of this is the write_below_etc macro used by Write below etc
     and not run_by_adclient
     and not qualys_writing_conf_files
     and not git_writing_nssdb
-...
+    ...
 ```
 
 The exceptions all generally follow the same structure--naming a program and a directory prefix below /etc where that program is allowed to write files.
 
 ## Rule Exceptions
 
-Starting in 0.28.0, falco supports an optional `exceptions` property to rules. The exceptions key is a list of identifier plus list of tuples of filtercheck fields. Here's an example:
+Starting in 0.28.0, falco supports an optional `exceptions` property to rules. The exceptions key is a {{< glossary_tooltip text="list" term_id="lists" >}} of identifier plus list of tuples of filtercheck fields. Here's an example:
 
 ```yaml
 - rule: Write below binary dir

content/en/docs/rules/special-characters.md

@@ -17,7 +17,7 @@ You can use `"` to capture these special characters. Here's an example:
   priority: WARNING
 ```
 
-When including items in lists, ensure that the double quotes are not interpreted from your YAML file by surrounding the quoted string with single quotes. Here's an example:
+When including items in {{< glossary_tooltip text="lists" term_id="lists" >}}, ensure that the double quotes are not interpreted from your YAML file by surrounding the quoted string with single quotes. Here's an example:
 
 ```yaml
 - list: systemd_procs

content/en/docs/rules/versioning.md

@@ -5,7 +5,7 @@ linktitle: Rules Versioning
 weight: 200
 ---
 
-From time to time, we make changes to the rules file format that are not backwards-compatible with older versions of Falco. Similarly, libsinsp and libscap may define new filtercheck fields, operators, etc. We want to denote that a given set of rules depends on the fields/operators from those libraries.
+From time to time, we make changes to the {{< glossary_tooltip text="rules file" term_id="rules-file" >}} format that are not backwards-compatible with older versions of Falco. Similarly, {{< glossary_tooltip text="libsinsp" term_id="libsinsp" >}} and {{< glossary_tooltip text="libscap" term_id="libscap" >}} may define new filtercheck fields, operators, etc. We want to denote that a given set of rules depends on the fields/operators from those libraries.
 
 There are currently two optional fields in the falco rules file related to versioning: