Merge pull request #1352 from gravwell/merge/next-patch_to_next-minor

chore: Merge next-patch into next-minor
gravwell · Jan 17, 2025 · 439ded2 · 439ded2
2 parents a43a8c3 + 3659a82
commit 439ded2
Show file tree

Hide file tree

Showing 10 changed files with 63 additions and 9 deletions.
diff --git a/_static/versions.json b/_static/versions.json
@@ -1,10 +1,14 @@
 [
   {
-    "name": "v5.6.9 (latest)",
-    "version": "v5.6.9",
+    "name": "v5.6.10 (latest)",
+    "version": "v5.6.10",
     "url": "/",
     "preferred": true
   },
+  {
+    "version": "v5.6.9",
+    "url": "/v5.6.9/"
+  },
   {
     "version": "v5.6.8",
     "url": "/v5.6.8/"

diff --git a/alerts/alerts.md b/alerts/alerts.md
@@ -13,6 +13,15 @@ In brief, _dispatchers_ send _events_, which are then processed by _consumers_.
 
 This page will show how to create and configure alerts, using as an example an alert which sends notifications whenever an admin-level account logs in, for instance when `root` logs in via ssh or `admin` logs in to Gravwell.
 
+```{important}
+There are a few important things to keep in mind regarding ownership & permissions when defining alerts:
+
+* An alert can use scheduled searches owned by other users as dispatchers, provided the alert owner has permission to view the results of those searches. Note that if the scheduled search owner changes permissions or deletes the search, the alert may no longer work properly.
+* An alert can use flows owned by other users as consumers, provided the alert owner has permission to view the flow. This has a variety of potential complications detailed below.
+  * If the flow uses resources, macros, secrets, or other items owned by the flow owner but not shared with the alert owner, the flow may not execute properly when triggered by the alert.
+  * The flow owner has the ability to modify the flow without notifying the alert owner; this means the alert may stop behaving properly, or in the case of a malicious flow owner, the flow could be used to e.g. leak the contents of the alert events.
+```
+
 ## Creating an Alert
 
 Alerts are defined in the Alerts page, found under the Automation sub-menu. Clicking "Create an alert" on this page will open a wizard to define a new alert:
@@ -144,6 +153,10 @@ When we click the Debug button in the Flows editor, we should shortly receive an
 
 ![](debug-email.png)
 
+```{note}
+When a flow is run in response to an actual alert trigger, the flow's results fields (payloads, last run time, etc.) are *not* updated, both to avoid leaking any sensitive material and because a single alert activation may run the same flow dozens of times, making updating the results less useful.
+```
+
 ### Adding a Flow Consumer
 
 Once the flow is defined, we can add it to our alert either through the Alert editor, or from the Settings tab of the Flow editor:

diff --git a/automation.md b/automation.md
@@ -3,11 +3,11 @@
 Gravwell provides several utilities to enable automated operations. At the most basic level, users can schedule searches to be executed at specific times, for example every morning at 1:00. They can also schedule flows and scripts, which can execute multiple searches, sift and parse search results, and send notifications via email or HTTP. Flows are designed using a drag-and-drop graphical interface and are generally preferred over scripts, which should be reserved for legacy situations or very particular use cases that flows cannot cover.
 
 ```{attention}
-An automation (Flow, Scheduled Search, or Script) runs as the user who owns the automation. 
+An automation (Flow, Scheduled Search, or Script) runs as the user who owns the automation, except when triggered by an alert.
 
-Granting write access to automations (currently Flows and Scheduled Searches) has important implications.
+Granting write access to an automation has important implications. When you grant a group write access to a Flow or Scheduled Search, you are granting them the ability to modify and execute it as **your user**. Consider using a machine user with the least privileges necessary as the owner of shared automations.
 
-When you grant a group write access to a Flow or Scheduled Search, you are granting them the ability to modify and execute it as **your user**. Consider using a machine user with the least privileges necessary as the owner of shared automations. 
+When a flow is run in response to an [alert](/alerts/alerts), it runs as the owner of the alert. This also has implications: the alert owner is executing code defined by the flow owner. Don't use flows owned by untrusted users as consumers on your alerts.
 ```
 
 ## Gravwell Automation

diff --git a/changelog/5.6.10.md b/changelog/5.6.10.md
@@ -0,0 +1,21 @@
+# Changelog for version 5.6.10
+
+## Released 17 January 2025
+
+## Gravwell
+
+### Additions
+
+* Added `has_key()` to eval to check for the existence of keys in a map.
+
+### Bug Fixes
+
+* Fixed an issue where search control requests forwarded between distributed webservers could lead to dangling connections.
+* Fixed an issue where the searchagent could "leak" previous searches when backfilling across multiple webservers.
+* Fixed an issue where Flows and Scripts that were backed up during kit upload were not properly prefixed with `Backup of`.
+
+## Ingester Changes
+
+### Bug Fixes
+
+* Updated dependencies and changed balancing strategy to remove deprecated functionality in Kafka Ingester.
diff --git a/changelog/list.md b/changelog/list.md
@@ -7,7 +7,7 @@
 maxdepth: 1
 caption: Current Release
 ---
-5.6.9 <5.6.9>
+5.6.10 <5.6.10>
 ```
 
 ## Previous Versions
@@ -18,6 +18,7 @@ maxdepth: 1
 caption: Previous Releases
 ---
 
+5.6.9 <5.6.9>
 5.6.8 <5.6.8>
 5.6.7 <5.6.7>
 5.6.6 <5.6.6>

diff --git a/conf.py b/conf.py
@@ -22,7 +22,7 @@
 project = "Gravwell"
 copyright = f"Gravwell, Inc. {date.today().year}"
 author = "Gravwell, Inc."
-release = "v5.6.9"
+release = "v5.6.10"
 
 # Default to localhost:8000, so the version switcher looks OK on livehtml
 version_list_url = os.environ.get(

diff --git a/flows/flows.md b/flows/flows.md
@@ -13,6 +13,14 @@ Flows provide a no-code method for developing advanced automations in Gravwell.
 
 This document will describe what makes a flow, the flow editor, and how to debug & deploy your own flows.
 
+```{attention}
+An automation (Flow, Scheduled Search, or Script) runs as the user who owns the automation, except when triggered by an alert.
+
+Granting write access to an automation has important implications. When you grant a group write access to a Flow or Scheduled Search, you are granting them the ability to modify and execute it as **your user**. Consider using a machine user with the least privileges necessary as the owner of shared automations.
+
+When a flow is run in response to an [alert](/alerts/alerts), it runs as the owner of the alert. This also has implications: the alert owner is executing code defined by the flow owner. Don't use flows owned by untrusted users as consumers on your alerts.
+```
+
 ## Basic flow concepts
 
 Flows are *automations*, meaning they are normally executed on a user-specified schedule by the search agent. You can also run them manually through the user interface. The basic process of flow development is:

diff --git a/gui/persistent/persistent.md b/gui/persistent/persistent.md
@@ -1,6 +1,6 @@
 # Persistent Searches
 
-Gravwell users may wish to [send long-running searches to the background or save search results](/gui/queries/queries), or [schedule searches](/scripting/scheduledsearch) to run periodically. To review the search results at a later time, use the *Persistent Searches* page, found in the Searches section of the main menu:
+Gravwell users may wish to [send long-running searches to the background](background_search), [save search results](search_results), or [schedule searches](/scripting/scheduledsearch) to run periodically. To review the search results at a later time, use the *Persistent Searches* page, found in the Searches section of the main menu:
 
 ![](persistent-menu.png)
 

diff --git a/gui/queries/queries.md b/gui/queries/queries.md
@@ -82,6 +82,7 @@ Finally, "ISO 8601 duration" allows you to specify a duration in [ISO-8601 forma
 "Preview" tells Gravwell to just go find "something" without regard to time.  This means that the system will look at the specific tags in use and ask the indexers for time ranges where the data could exist and then begin sampling it.  The data may be in the future or it may be way in the past.  This is a good option for testing queries.
 ```
 
+(search_results)=
 ## Search Results Page
 
 When you run a query, Gravwell displays the *search results page* to show the output. From this page, you can drill down into subsections of the results, modify & re-run the query, change the timeframe, save the results, and more.
@@ -165,7 +166,7 @@ Note that the timeframe button on the query bar now has a dot on it. This indica
 ```{note}
 Not all queries will display the timeframe selector. Some modules or module options (like the table renderer's `-nt` flag) force Gravwell into *non-temporal mode*, which disallows zooming.
 ```
-
+(background_search)=
 ## Run search in background
 
 This option is useful when a search is taking longer than expected to complete. Clicking "Run search in background" will make the search continue running in the background even after you navigate away from the results page; this allows you to do other things while the search completes. You can monitor the search's status and view the completed results from the [Persistent Searches](/gui/persistent/persistent) page. Note that backgrounded searches do *not* persist across webserver restarts; to keep results around permanently, use the "Save results" option.

diff --git a/search/eval/eval.md b/search/eval/eval.md
@@ -439,6 +439,12 @@ Deletes the given enumerated value.
 
 Returns true if the given EV exists.
 
+#### has_key
+
+	function has_key(map string, key string) bool
+
+Returns true if the given key exists in the given map.
+
 #### in
 
 	function in(ev string, string...) bool