sentinel_one_cloud_funnel: fix routing and add S3-compatible endpoint configuration - #20467
sentinel_one_cloud_funnel: fix routing and add S3-compatible endpoint configuration#20467efd6 wants to merge 1 commit into
Conversation
efd6
added
enhancement
80525e6 to
7dfcae8
Compare
Elastic Docs Style Checker (Vale)Summary: 1 warning, 2 suggestions found
|
| File | Line | Rule | Message |
|---|---|---|---|
| packages/sentinel_one_cloud_funnel/manifest.yml | 82 | Elastic.Latinisms | Latin terms and abbreviations are a common source of confusion. Use 'for example' instead of 'e.g'. |
💡 Suggestions (2): Optional style improvements. Apply when helpful.
| File | Line | Rule | Message |
|---|---|---|---|
| packages/sentinel_one_cloud_funnel/_dev/build/docs/README.md | 100 | Elastic.Ellipses | In general, don't use an ellipsis. |
| packages/sentinel_one_cloud_funnel/_dev/build/docs/README.md | 103 | Elastic.Semicolons | Use semicolons judiciously. |
The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.
7dfcae8 to
da33083
Compare
|
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
![vera-review-bot[bot]](https://avatars.githubusercontent.com/in/3297022?s=60&v=4){kind=small}
| type: constant_keyword | ||
| description: Event dataset. | ||
| value: sentinel_one_cloud_funnel.event | ||
| value: sentinel_one_cloud_funnel.logins |
There was a problem hiding this comment.
Severity: 🟠 High confidence: high path: packages/sentinel_one_cloud_funnel/data_stream/logins/fields/base-fields.yml:17
The logins data stream declares dataset 'sentinel_one_cloud_funnel.login' (singular) but this line pins event.dataset to 'sentinel_one_cloud_funnel.logins' (plural), so login events still will not route correctly; change data_stream/logins/manifest.yml to 'dataset: sentinel_one_cloud_funnel.logins' to match this value, routing_rules.yml and the reroute_logins option.
Details
Every other data stream touched by this PR sets event.dataset to its own dataset name, but logins is the one place where the two disagree.
data_stream/logins/manifest.yml:2declaresdataset: sentinel_one_cloud_funnel.login(singular), so Fleet installs the index template forlogs-sentinel_one_cloud_funnel.login-*.data_stream/event/routing_rules.yml:28targetstarget_dataset: sentinel_one_cloud_funnel.logins(plural), as do thereroute_loginsoption titles/descriptions in the root manifest (lines 246, 251, 378, 383, 495, 500).- This line now pins
event.datasettosentinel_one_cloud_funnel.loginsinside thelogs-sentinel_one_cloud_funnel.login-*template.
Two concrete consequences today:
- Rerouted login events are written to
logs-sentinel_one_cloud_funnel.logins-<ns>. That name does not match the index patternlogs-sentinel_one_cloud_funnel.login-*(the character after the literalloginiss, not-), so the package's mappings,beats.yml/fields.ymldefinitions and analyzer settings are never applied — the documents fall through to the genericlogs-*-*template. - The
logs-sentinel_one_cloud_funnel.login-*template that this line does apply to now has aconstant_keywordevent.datasetwhose value can never equal its owndata_stream.dataset.
So the PR's stated fix ("Fix event.dataset constant_keyword values for routing target data streams, allowing rerouted events to be correctly indexed") holds for the other twelve targets but not for logins. The new routed_data_streams.txt script test only exercises the dns and process routes, and elastic-package check does not cross-check a constant_keyword event.dataset value against the data stream's dataset (CI on this PR is green), so nothing catches this automatically.
sentinel_one_cloud_funnel.login appears exactly once in the whole package — in data_stream/logins/manifest.yml. The plural spelling is used everywhere else, including the directory name, so the manifest is the odd one out.
Recommendation:
Keep this line as sentinel_one_cloud_funnel.logins and correct the data stream's declared dataset instead, in packages/sentinel_one_cloud_funnel/data_stream/logins/manifest.yml:
title: SentinelOne Cloud Funnel Logins Events
dataset: sentinel_one_cloud_funnel.logins
type: logs
elasticsearch:
index_template:
settings:
analysis:
analyzer:
powershell_script_analyzer:
type: pattern
pattern: '[\W&&[^-]]+'This aligns the data stream with routing_rules.yml, the reroute_logins option text and the directory name, and no existing data is orphaned because the routing path was broken before this PR (missing dynamic_dataset plus the wrong event.dataset value), so logs-sentinel_one_cloud_funnel.login-* has never received rerouted documents.
If you would rather not change the installed data stream name, the alternative is to make this file and the routing rule both use the singular form — but then routing_rules.yml and every reroute_logins title/description in the root manifest need updating too:
# data_stream/logins/fields/base-fields.yml
- name: event.dataset
type: constant_keyword
description: Event dataset.
value: sentinel_one_cloud_funnel.login# data_stream/event/routing_rules.yml
- target_dataset: sentinel_one_cloud_funnel.login
if: ctx.sentinel_one_cloud_funnel?.event?.category == 'logins' && ctx.sentinel_one_cloud_funnel?.event?.rerouted == true
namespace:
- '{{data_stream.namespace}}'
- defaultWhichever direction you pick, consider extending routed_data_streams.txt with a logins event so the route is covered by the new script test.
🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
⚠️ Automated review — verify suggestions before applying.
| multi: false | ||
| required: false | ||
| show_user: false | ||
| description: Name of the S3 bucket for use with S3-compatible services (e.g. MinIO, Ceph). Use instead of Bucket ARN when not connecting to AWS S3. |
There was a problem hiding this comment.
Severity: 🔵 Low confidence: medium path: packages/sentinel_one_cloud_funnel/manifest.yml:82
The S3-compatible options (non_aws_bucket_name, endpoint, path_style, region) are all show_user: false and unmentioned in the README, so a MinIO/Ceph user only sees Bucket ARN and Access Point ARN; document the S3-compatible flow in _dev/build/docs/README.md.
Details
non_aws_bucket_name, endpoint, path_style and region are all added with show_user: false, which matches the convention in packages/aws_logs/data_stream/generic/manifest.yml. The gap is that nothing tells a user this path exists: _dev/build/docs/README.md only documents the AWS S3 polling and AWS SQS modes, and the two visible bucket options (bucket_arn, access_point_arn, both show_user: true) still describe themselves as the only choices — bucket_arn says it is required "unless you set an Access Point ARN" and access_point_arn says it is "Mandatory if the 'Collect logs via S3 Bucket' switch is on". Neither mentions the third alternative this PR introduces.
There is also a hard requirement that is easy to miss: the Filebeat aws-s3 docs state that region is required when non_aws_bucket_name is defined, and that endpoint must be a full URI of the form http(s)://<s3 endpoint> in that case. The manifest cannot express a conditional required, so the README is the only place this can be conveyed. Without it, a misconfigured policy fails at agent runtime with no hint from the UI.
Recommendation:
Add a short subsection to packages/sentinel_one_cloud_funnel/_dev/build/docs/README.md under "Collect data from an AWS S3 bucket", for example:
### Collect data from an S3-compatible service (MinIO, Ceph, ...)
Under **Advanced options**, instead of a Bucket ARN or Access Point ARN, set:
- **[S3] Non-AWS Bucket Name** — the bucket name on the S3-compatible service.
- **Endpoint** — the full service URI, including the scheme, for example `https://s3.example.com:9000`.
- **Region** — required whenever a Non-AWS Bucket Name is set.
- **Path Style** — enable this; S3-compatible services generally require path-style access.
Authentication must use **Access Key ID** and **Secret Access Key**; IAM roles and shared credential profiles are AWS-only.Optionally, also point the two visible bucket options at the alternative so the UI is self-consistent:
- name: bucket_arn
type: text
title: "[S3] Bucket ARN"
multi: false
required: false
show_user: true
description: ARN of the AWS S3 bucket that will be polled for list operation. Required when collecting logs via the AWS S3 Bucket unless you set an Access Point ARN, or a Non-AWS Bucket Name for an S3-compatible service. In case both configurations are added, this one takes precedence.🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
⚠️ Automated review — verify suggestions before applying.
0b1374f to
2ba6495
Compare
| type: constant_keyword | ||
| description: Event dataset. | ||
| value: sentinel_one_cloud_funnel.event | ||
| value: sentinel_one_cloud_funnel.login |
There was a problem hiding this comment.
Severity: 🟠 High confidence: high path: packages/sentinel_one_cloud_funnel/data_stream/logins/fields/base-fields.yml:17
The logins routing target is still broken: routing_rules.yml reroutes to 'sentinel_one_cloud_funnel.logins' (plural) but this pins event.dataset to 'sentinel_one_cloud_funnel.login' (singular), matching data_stream/logins/manifest.yml; rename the logins dataset to the plural form in both files so it matches the routing rule.
Details
Every other data stream in this PR now pins event.dataset to the value used by its routing rule, but logins does not.
- data_stream/event/routing_rules.yml:28 -> target_dataset: sentinel_one_cloud_funnel.logins
- data_stream/event/routing_rules.yml:29 -> if category == 'logins' (matching _dev/test/pipeline/test-login.log, which carries "event.category":"logins")
- manifest.yml:246/251, 378/383, 495/500 -> the reroute_logins var title and description both say sentinel_one_cloud_funnel.logins
- data_stream/logins/manifest.yml:2 -> dataset: sentinel_one_cloud_funnel.login
- this line -> value: sentinel_one_cloud_funnel.login
The reroute processor sends login events to logs-sentinel_one_cloud_funnel.logins-, but the package only installs an index template for logs-sentinel_one_cloud_funnel.login-*. Rerouted login documents therefore land in a data stream with no package mappings, so the logins fields and the constant_keyword changed on this line are never applied. logins is the only routing target this PR does not fix.
Renaming the data stream dataset to the plural form is safe here: nothing else in the package references sentinel_one_cloud_funnel.login (no dashboards, no pipelines), and because routing has been broken up to now the singular data stream has never received rerouted documents.
Recommendation:
Make the logins dataset plural so it matches routing_rules.yml and the reroute_logins option.
In data_stream/logins/manifest.yml:
title: SentinelOne Cloud Funnel Logins Events
dataset: sentinel_one_cloud_funnel.logins
type: logsAnd on this line in data_stream/logins/fields/base-fields.yml:
- name: event.dataset
type: constant_keyword
description: Event dataset.
value: sentinel_one_cloud_funnel.logins🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
⚠️ Automated review — verify suggestions before applying.
|
|
||
| ### Collect data from an S3-compatible service (MinIO, Ceph, ...) | ||
|
|
||
| Under **Advanced options**, instead of a Bucket ARN or Access Point ARN, set: |
There was a problem hiding this comment.
Severity: 🟡 Medium confidence: high path: packages/sentinel_one_cloud_funnel/_dev/build/docs/README.md:102
The new S3-compatible section omits the required first step of enabling the 'Collect logs via S3 Bucket' toggle, so a user following it verbatim gets a policy that silently collects nothing; add that step before the Advanced options list.
Details
In data_stream/event/agent/stream/aws-s3.yml.hbs the non_aws_bucket_name key is emitted only inside the {{#if collect_s3_logs}} branch (lines 1-9), and it is the third arm of the bucket_arn / access_point_arn / non_aws_bucket_name chain. The collect_s3_logs var defaults to false (manifest.yml:61), so a user who follows this section as written -- setting only Non-AWS Bucket Name, Endpoint, Region and Path Style under Advanced options -- produces an agent policy that takes the SQS branch, never renders non_aws_bucket_name, and has no queue_url either. No data is collected and no configuration error is surfaced.
The same text is duplicated at docs/README.md:102; fixing the source template and regenerating covers both.
Recommendation:
State the toggle as an explicit first step:
### Collect data from an S3-compatible service (MinIO, Ceph, ...)
1. Enable the **Collect logs via S3 Bucket** toggle. The S3-compatible options below only
take effect in bucket-polling mode; with the toggle off the agent runs in SQS mode and
ignores the Non-AWS Bucket Name.
2. Under **Advanced options**, instead of a Bucket ARN or Access Point ARN, set:
- **[S3] Non-AWS Bucket Name** — the bucket name on the S3-compatible service.
- **Endpoint** — the full service URI, including the scheme, for example `https://s3.example.com:9000`.
- **Region** — required whenever a Non-AWS Bucket Name is set.
- **Path Style** — enable this; S3-compatible services generally require path-style access.
Authentication must use **Access Key ID** and **Secret Access Key**; IAM roles and shared credential profiles are AWS-only.🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
⚠️ Automated review — verify suggestions before applying.
| multi: false | ||
| required: false | ||
| show_user: false | ||
| description: Name of the S3 bucket for use with S3-compatible services (e.g. MinIO, Ceph). Use instead of Bucket ARN when not connecting to AWS S3. |
There was a problem hiding this comment.
Severity: 🔵 Low confidence: medium path: packages/sentinel_one_cloud_funnel/manifest.yml:82
Adding non_aws_bucket_name as a third bucket option makes the neighbouring bucket_arn and access_point_arn descriptions inaccurate (they still claim one of the two ARNs is mandatory); update those two descriptions to mention the Non-AWS Bucket Name alternative.
Details
aws-s3.yml.hbs now selects between three mutually exclusive options: bucket_arn, access_point_arn, non_aws_bucket_name. The existing UI descriptions were written for two:
- manifest.yml:68 (bucket_arn): "It is a required parameter for collecting logs via the AWS S3 Bucket unless you set an Access Point ARN."
- manifest.yml:75 (access_point_arn): "Mandatory if the "Collect logs via S3 Bucket" switch is on. It is a required parameter for collecting logs via the AWS S3 Bucket unless you set a Bucket ARN."
Both statements are now false for the S3-compatible flow this PR adds, and they are the descriptions a MinIO/Ceph user reads first because those two vars are show_user: true while non_aws_bucket_name is not.
Recommendation:
Mention the third option in both descriptions:
- name: bucket_arn
type: text
title: "[S3] Bucket ARN"
multi: false
required: false
show_user: true
description: ARN of the AWS S3 bucket that will be polled for list operation. Required for collecting logs via the AWS S3 Bucket unless you set an Access Point ARN, or a Non-AWS Bucket Name for an S3-compatible service. In case both configurations are added, this one takes precedence.
- name: access_point_arn
type: text
title: "[S3] Access Point ARN"
multi: false
required: false
show_user: true
description: ARN of the AWS S3 Access Point that will be polled for list operation. Required for collecting logs via the AWS S3 Bucket unless you set a Bucket ARN, or a Non-AWS Bucket Name for an S3-compatible service.🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
⚠️ Automated review — verify suggestions before applying.
… configuration Fix two bugs that prevented routing rules from working: 1. Correct event.dataset constant_keyword values in all 13 routing target data streams (they all incorrectly used the source dataset name instead of their own). 2. Add dynamic_dataset and dynamic_namespace to the event data stream manifest so Fleet grants the agent's output API key write access to routing target indices. Also add endpoint, path_style, region, and non_aws_bucket_name variables to the aws-s3 input so the package can collect from S3-compatible services such as MinIO. Includes a script test that verifies routing end-to-end using MinIO.
2ba6495 to
11dbf1d
Compare
|
✅ All changelog entries have the correct PR link. |
🚀 Benchmarks reportTo see the full report comment with |
💚 Build Succeeded
History
cc @efd6 |
| # newer versions go on top | ||
| - version: "1.14.0" | ||
| changes: | ||
| - description: Fix event.dataset constant_keyword values for routing target data streams, allowing rerouted events to be correctly indexed. |
There was a problem hiding this comment.
Severity: 🟡 Medium confidence: high path: packages/sentinel_one_cloud_funnel/changelog.yml:4
The 1.14.0 changelog does not mention that the logins data stream dataset was renamed from sentinel_one_cloud_funnel.login to .logins; add an entry for it since the backing index name changes for existing users.
Details
packages/sentinel_one_cloud_funnel/data_stream/logins/manifest.yml changes dataset from sentinel_one_cloud_funnel.login to sentinel_one_cloud_funnel.logins. That renames the index template and the data stream backing the logins stream (logs-sentinel_one_cloud_funnel.login-* -> logs-sentinel_one_cloud_funnel.logins-*), which is user-visible on upgrade: any saved search, detection rule, or ES|QL query pinned to the old dataset stops matching, and previously ingested .login documents are no longer covered by a package-managed index template. The three entries added for 1.14.0 cover the event.dataset constant_keyword fix, dynamic_dataset/dynamic_namespace, and the new S3-compatible options, but none of them describes this rename, so nothing in the changelog tells an upgrading user their logins index name changed. This is also the kind of change the repo's breaking-change detector reports, so an explicit entry avoids a surprise later in CI.
Recommendation:
Add a dedicated entry describing the rename (use breaking-change if the team agrees the index rename is breaking for existing installs):
- version: "1.14.0"
changes:
- description: Rename the logins data stream dataset from `sentinel_one_cloud_funnel.login` to `sentinel_one_cloud_funnel.logins` so it matches the routing rule target. Existing data indexed under `logs-sentinel_one_cloud_funnel.login-*` is no longer written to.
type: breaking-change
link: https://github.com/elastic/integrations/pull/20467
- description: Fix event.dataset constant_keyword values for routing target data streams, allowing rerouted events to be correctly indexed.
type: bugfix
link: https://github.com/elastic/integrations/pull/20467🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
⚠️ Automated review — verify suggestions before applying.
There was a problem hiding this comment.
It never worked, so I'm OK with this.
| @@ -1,5 +1,7 @@ | |||
| title: Collect Event logs from SentinelOne Cloud Funnel. | |||
| elasticsearch: | |||
| dynamic_dataset: true | |||
There was a problem hiding this comment.
Severity: 🟡 Medium confidence: medium path: packages/sentinel_one_cloud_funnel/data_stream/event/manifest.yml:3
Rerouted events now index successfully but every shipped dashboard filters on data_stream.dataset == sentinel_one_cloud_funnel.event, so routed documents are invisible; widen the dashboard filters to cover the routing targets.
Details
Before this PR, a document rerouted to sentinel_one_cloud_funnel.dns carried event.dataset: sentinel_one_cloud_funnel.dns but landed in an index whose template declared event.dataset as constant_keyword with value sentinel_one_cloud_funnel.event, so it was rejected. With the base-fields fix plus dynamic_dataset/dynamic_namespace here, those documents are now indexed into logs-sentinel_one_cloud_funnel.<category>-*.
All six dashboards and the saved search in kibana/ carry a top-level phrase filter data_stream.dataset: sentinel_one_cloud_funnel.event (for example kibana/dashboard/sentinel_one_cloud_funnel-724f8d70-f966-11ed-b51d-ef5658e04999.json lines 16-26, and the same filter in the 008e94d0, 42ecf8a0, afecde30, c90a2bc0 and dd209080 dashboards). Any user who turns on a reroute_* option therefore sees those events disappear from the DNS, Login, Network Action, Registry, Threat Intelligence Indicator and URL dashboards, because the routed documents no longer have data_stream.dataset: sentinel_one_cloud_funnel.event.
Recommendation:
Replace the single phrase filter with one that also matches the routing targets, e.g. a data_stream.dataset prefix/is one of filter on each dashboard and the saved search:
{
"$state": { "store": "appState" },
"meta": {
"alias": "SentinelOne Cloud Funnel datasets",
"disabled": false,
"indexRefName": "kibanaSavedObjectMeta.searchSourceJSON.filter[0].meta.index",
"key": "data_stream.dataset",
"negate": false,
"params": ["sentinel_one_cloud_funnel.event", "sentinel_one_cloud_funnel.dns"],
"type": "phrases"
},
"query": {
"bool": {
"minimum_should_match": 1,
"should": [
{ "match_phrase": { "data_stream.dataset": "sentinel_one_cloud_funnel.event" } },
{ "match_phrase": { "data_stream.dataset": "sentinel_one_cloud_funnel.dns" } }
]
}
}
}If updating the dashboards is out of scope for this PR, please note the limitation in the README section that documents the rerouting options.
🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
⚠️ Automated review — verify suggestions before applying.
| required: false | ||
| show_user: false | ||
| default: "" | ||
| description: URL of the entry point for an AWS web service. If set, the input will use this endpoint instead of the default AWS endpoint. |
There was a problem hiding this comment.
Severity: 🔵 Low confidence: medium path: packages/sentinel_one_cloud_funnel/manifest.yml:186
The Endpoint variable description shown in Fleet does not say the value must be a full URI including the scheme, unlike the README; restate the requirement in the manifest description.
Details
The Filebeat aws-s3 input requires endpoint to be a full URI of the form http(s)://<s3 endpoint> when non_aws_bucket_name is used (see the S3-compatible services section of https://www.elastic.co/docs/reference/beats/filebeat/filebeat-input-aws-s3). The README added in this PR states that correctly ("the full service URI, including the scheme, for example https://s3.example.com:9000"), but the manifest description, which is the text a user actually sees next to the field in Fleet, only says "URL of the entry point for an AWS web service. If set, the input will use this endpoint instead of the default AWS endpoint." A user who follows the Fleet UI alone can enter a bare host such as s3.example.com:9000 and the input will fail to connect. The same section is also where the region requirement is worth restating, which the region var already does.
Recommendation:
Make the in-product description match the README and the Filebeat requirement:
- name: endpoint
type: text
title: Endpoint
multi: false
required: false
show_user: false
default: ""
description: Full URI of the S3 service endpoint, including the scheme, for example `https://s3.example.com:9000`. Required when using a Non-AWS Bucket Name for an S3-compatible service. Leave empty to use the default AWS endpoint.🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
⚠️ Automated review — verify suggestions before applying.
|
|
||
| -- s1cf-minio/testdata/events.ndjson -- | ||
| {"event.category":"dns","event.time":1664811149495,"event.id":"TEST_DNS_001","event.type":"DNS Resolved","meta.event.name":"DNS","site.id":"123456789","account.id":"123456789","endpoint.name":"test-host","endpoint.os":"windows","endpoint.type":"laptop","agent.uuid":"test-agent-1","agent.version":"22.1.2.217","mgmt.id":"1337","mgmt.url":"test.sentinelone.org","os.name":"Windows10Pro","src.process.name":"chrome.exe","src.process.pid":1234,"src.process.uid":"AAAA0000","process.unique.key":"AAAA0000","trace.id":"TEST_DNS_001","packet.id":"PKT001","event.dns.request":"example.com","event.dns.response":"93.184.216.34","dataSource.name":"SentinelOne","dataSource.category":"security","i.scheme":"edr","i.version":"preprocess-lib-1.0","site.name":"TEST","group.id":"test-group","sca:atlantisIngestTime":1664811166298,"sca:ingestTime":1664811166,"timestamp":"18:32:29.495"} | ||
| {"event.category":"dns","event.time":1664811150000,"event.id":"TEST_DNS_002","event.type":"DNS Resolved","meta.event.name":"DNS","site.id":"123456789","account.id":"123456789","endpoint.name":"test-host","endpoint.os":"windows","endpoint.type":"laptop","agent.uuid":"test-agent-1","agent.version":"22.1.2.217","mgmt.id":"1337","mgmt.url":"test.sentinelone.org","os.name":"Windows10Pro","src.process.name":"firefox.exe","src.process.pid":5678,"src.process.uid":"BBBB0000","process.unique.key":"BBBB0000","trace.id":"TEST_DNS_002","packet.id":"PKT002","event.dns.request":"elastic.co","event.dns.response":"34.120.115.39","dataSource.name":"SentinelOne","dataSource.category":"security","i.scheme":"edr","i.version":"preprocess-lib-1.0","site.name":"TEST","group.id":"test-group","sca:atlantisIngestTime":1664811166298,"sca:ingestTime":1664811166,"timestamp":"18:32:30.000"} |
There was a problem hiding this comment.
Severity: 🔵 Low confidence: medium path: packages/sentinel_one_cloud_funnel/data_stream/event/_dev/test/scripts/routed_data_streams.txt:95
The new routing test fixture uses real routable IP addresses and a real domain instead of documentation placeholders; replace them with RFC 5737 addresses and example.com.
Details
The s1cf-minio/testdata/events.ndjson records embedded in this txtar file use event.dns.response values 93.184.216.34 (line 94) and 34.120.115.39 (line 95) and an event.dns.request of elastic.co (line 95). These are real, routable addresses belonging to real infrastructure rather than synthetic placeholders. Committed integration fixtures are expected to use the documentation ranges (RFC 5737: 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) and example.com-style names, so that geo/ASN enrichment and any downstream analysis in tests never resolve to a real organisation. The existing pipeline fixtures in this data stream already follow that convention (blog.example.com, infra-cdn.example.com).
Recommendation:
Swap the values for documentation-range equivalents; the routing assertions only depend on event.category, so nothing else needs to change:
{"event.category":"dns","event.id":"TEST_DNS_001","event.dns.request":"blog.example.com","event.dns.response":"192.0.2.10"}
{"event.category":"dns","event.id":"TEST_DNS_002","event.dns.request":"infra-cdn.example.com","event.dns.response":"198.51.100.24"}🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
⚠️ Automated review — verify suggestions before applying.
Review summaryIssues found across the latest commits 11dbf1d — 2 medium, 2 low
Issues found across earlier commits 2ba6495 — 1 high, 1 medium, 1 low
Issues found across earlier commits da33083 — 1 high, 1 low
🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
|
1 participant
Proposed commit message
Checklist
changelog.ymlfile.Author's Checklist
How to test this PR locally
Related issues
Screenshots