docs: update executor configuration to UI-based (Catalog)#303
Open
DeniseMonreale wants to merge 4 commits into
Open
docs: update executor configuration to UI-based (Catalog)#303DeniseMonreale wants to merge 4 commits into
DeniseMonreale wants to merge 4 commits into
Conversation
- Remove environment variable / property columns from all executor config tables - Update instructions to configure via Integrations > Executors UI - Add migration info note for users previously using env vars - Applies to: Tanium, CrowdStrike, SentinelOne, Palo Alto Cortex, Caldera Closes #252
There was a problem hiding this comment.
Pull request overview
Updates executor configuration documentation to match the current UI-based (Catalog) configuration model, removing outdated guidance around environment variables/platform properties that are no longer read after first startup migration.
Changes:
- Reworked configuration instructions for Tanium, CrowdStrike, SentinelOne, Palo Alto Cortex, and Caldera to point users to Integrations > Executors in the UI.
- Simplified executor configuration tables to UI-facing parameter names (dropping env var/property columns).
- Added a repeated migration note explaining one-time import of existing env var/property values into the database and that subsequent env var/property changes are ignored.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Member
|
@DeniseMonreale I think we can remove all the variables here to avoid maintenance issues as executors evolve, and instead let users go directly to the UI to make the changes. |
- Fix API version: "v1" → "1.0" (matches code) - Fix Register Interval description: "accounts/sites/groups/agents" → "groups/endpoints" (matches code) - Remove migration info block for Palo Alto (never had env vars, no migration class exists)
| | Group Name | | Palo Alto Cortex group name or group names separated with commas | | ||
| | Windows Script UID | | UID of the OpenAEV Palo Alto Cortex Windows script | | ||
| | Unix Script UID | | UID of the OpenAEV Palo Alto Cortex Unix script | | ||
|
|
Member
There was a problem hiding this comment.
There is no migration for Palo Alto because it was introduced after the builtin migrations manager. How likely it is that people would have activated the executor via props/env vars? Note the code is completely absent.
| | Parameter | Default value | Description | | ||
| |:-----------------------------------|:--------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | ||
| | Enable | `false` | Enable the Palo Alto Cortex executor | | ||
| | URL | | Palo Alto Cortex URL, the API version used is the 1.0 | |
| | Parameter | Default value | Description | | ||
| |:-----------------------------------|:--------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------| | ||
| | Enable | `false` | Enable the SentinelOne executor | | ||
| | URL | | SentinelOne URL, the API version used is the 2.1 | |
Option A: remove all executor configuration parameter tables to avoid maintenance issues as executors evolve. Users are now directed to configure executors directly from the Integrations > Executors UI. Migration notes are kept for Tanium, CrowdStrike, SentinelOne, and Caldera (executors that had env vars before the Catalog system). Palo Alto Cortex has no migration note (added after Catalog).
- Fix intro table: "Crowdstrike" → "CrowdStrike" (capital S, official branding) - Fix 3 SentinelOne image alt texts: - "unix script1" → "unix script2" (for sentinelone-unix-script2.png) - "unix script1" → "windows script1" (for sentinelone-windows-script1.png) - "unix script1" → "windows script2" (for sentinelone-windows-script2.png)
antoinemzs
approved these changes
May 29, 2026
Member
antoinemzs
left a comment
antoinemzs
left a comment
There was a problem hiding this comment.
looks good. The note about Palo Alto is incorrect in that there is no migration provisioned for Palo Alto Cortex. It might have been an oversight but that just means that Palo Alto will not be activated by props alone. It wil need to be explicitly activated through the UI, which is what the docs now state. So IMO it's fine as it is.
|
|
||
| !!! info "Migrating from environment variables" | ||
|
|
||
| If you previously configured this executor using environment variables or platform properties, these values have been **automatically migrated** to the database on first startup. After migration, changes to environment variables or properties are no longer taken into account — all configuration is now managed through the UI. |
| | Group Name | | Palo Alto Cortex group name or group names separated with commas | | ||
| | Windows Script UID | | UID of the OpenAEV Palo Alto Cortex Windows script | | ||
| | Unix Script UID | | UID of the OpenAEV Palo Alto Cortex Unix script | | ||
|
|
Member
There was a problem hiding this comment.
There is no migration for Palo Alto because it was introduced after the builtin migrations manager. How likely it is that people would have activated the executor via props/env vars? Note the code is completely absent.
DeniseMonreale
requested review from
MarineLeM and
Copilot
and removed request for
MarineLeM and
Seb-MIGUEL
| | executor.caldera.api-key | EXECUTOR_CALDERA_API-KEY | | Caldera API key | | ||
| !!! info "Migrating from environment variables" | ||
|
|
||
| If you previously configured this executor using environment variables or platform properties, these values have been **automatically migrated** to the database on first startup. After migration, changes to environment variables or properties are no longer taken into account — all configuration is now managed through the UI. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Update the executor configuration documentation to reflect the current behavior: executors are now configured exclusively through the Integrations > Executors UI (Catalog system), not via environment variables or platform properties.
Changes
For all 5 executors (Tanium, CrowdStrike, SentinelOne, Palo Alto Cortex, Caldera):
!!! info "Migrating from environment variables"note (for Tanium, CrowdStrike, SentinelOne, Caldera only) explaining that existing env var / property values are automatically migrated to the database on first startup, and that subsequent changes to env vars are silently ignoredAdditional fixes (pre-existing issues)
Context
With XTM Composer, executor configuration is now stored in the database and managed through the UI. The backend performs a one-time migration of existing properties/env vars into the database. After this migration, the backend no longer reads properties or env vars — only the database values are used.
The previous documentation was misleading as it instructed users to set environment variables that would be silently ignored after the first startup. By removing all parameter tables, we also eliminate future maintenance burden as executors evolve.
Closes #252