Repository navigation
feat: redact sensitive values in notification files when exporting a CrowdSec configuration #1551
Description
What: the CrowdSec export keeps the notification configuration files, because a profile that names a notification with no file stops CrowdSec from loading its configuration. Those files can contain sensitive values. Redacting the values while keeping the files would make an export safer to share.
Where: ExportConfig / ImportConfig in backend/internal/api/handlers/crowdsec_handler.go; the notification handling added in #1546.
Suggested approach: a structural allowlist of keys per notification plugin, a yaml.Node rewrite that keeps anchors/aliases working, and an import merge that keeps the running system's values for files that already exist. Keep non-secret personal fields as they are. Any "needs attention" message should be inline in the import card, not a banner.
Related: #1539 (decision to keep these files for now), #1546.
Severity: low.
Metadata
Metadata
Assignees
Projects
- Status
Activity
Wikid82 commentedon Oct 11, 2026
Related finding from the #1545 manual check: the bundled image ships no CrowdSec notification plugin directory (
/usr/local/lib/crowdsec/pluginsis absent), socrowdsec -tfails with 'loading plugin: open /usr/local/lib/crowdsec/plugins: no such file or directory' as soon as a profile names any notification, whether or not the notification file exists. Notifications therefore cannot load in this image today; whatever is decided about redacting notification files should also decide whether the image should ship the plugins.Wikid82 commentedon Oct 11, 2026
Correction while planning: CrowdSec 1.8.1 ships a
sentinelnotification plugin, notsentry; the plugins are dummy, email, file, http, sentinel, slack and splunk. Implementation is in #1565.