[security] Scoping Collections to node-level assets for vulnerability reporting

docs/en/solutions/Scoping_Collections_to_node_level_assets_for_vulnerability_reporting.md

@@ -0,0 +1,60 @@
+---
+kind:
+   - Information
+products:
+   - Alauda Container Platform
+ProductsVersion:
+   - 4.1.0,4.2.x
+---
+## Overview
+
+The runtime security and vulnerability-management capability used by ACP (the `Container Security` extension, which is built on the open-source StackRox project) exposes a `Collection` abstraction for grouping assets. Collections are then consumed by Vulnerability Report schedules, RBAC-style access scopes, and policy enforcement scopes, so their expressive power directly constrains what kinds of reports the platform can produce on a recurring basis.
+
+A common request from operators is to schedule a vulnerability report that covers **node-level CVEs only** — for example the OS packages installed on the worker nodes — independently of the containerized workloads running on those nodes. This article documents where that capability stands today and what options exist in the meantime.
+
+## Current Behaviour
+
+Collections currently accept selectors over three asset types:
+
+- **Clusters** — one or more secured clusters registered with the central component.
+- **Namespaces** — namespaces across the selected clusters, by name or by label.
+- **Deployments** — workloads (Deployments/StatefulSets/…) within the selected namespaces, by name or by label.
+
+Nodes are **not** a supported scope type on a `Collection`. As a consequence:
+
+- You cannot build a Collection that filters to "nodes matching label X" or "the worker nodes of cluster Y".
+- Vulnerability Report schedules that consume a Collection therefore cannot be narrowed to "node OS CVEs for this node group" at the Collection layer.
+- Access scopes and policy scopes inherit the same limitation for node-only targeting.
+
+Node-level CVE data itself is still collected by the scanner and visible in the Vulnerability Management views and via the API; the gap is purely in the *scheduled report / Collection binding* surface.
+
+## Status
+
+Extending Collections with a node-level scope is a tracked feature request against the upstream StackRox project (and the corresponding security extension shipped with ACP). Until it ships, plan around the current scope types below.
+
+## Workarounds
+
+### 1. Report at cluster granularity, filter at render time
+
+Create a Collection that selects the cluster(s) you care about and schedule a Vulnerability Report against it. Then filter the rendered report (or its CSV export) down to node findings downstream — most consumers already post-process the report into their own dashboard, so a `component-type = node` / `image == <node-os>` filter step is enough to extract the node-level rows.
+
+Pros: works today with zero API/UI change. Cons: the scheduled email/export carries workload CVEs you then discard.
+
+### 2. Query the vulnerability API directly on a cron
+
+If you want node-only output delivered on a schedule without the post-filter step, bypass the Collection-driven scheduler and hit the vulnerability-management API directly from a small job running inside the cluster. A `CronJob` backed by a ServiceAccount with read access to the security API can:
+
+1. Issue a GraphQL / REST query for node CVEs over the cluster or node set you care about.
+2. Serialize the response to CSV / JSON.
+3. Push the artifact to object storage or a notification channel.
+
+This pattern is explicitly supported — the same queries the Collection-driven report would eventually issue are exposed on the public API surface today.
+
+### 3. Use Cluster + Namespace scopes to approximate "node infra"
+
+Some operators carve node-infrastructure workloads (daemonsets, node exporters) into a dedicated namespace and schedule the report against `cluster=<id>, namespace=<node-infra-ns>`. This does not change what "node-level CVEs" means — node OS CVEs still come from the scanner's node component, not from the namespace — but it is useful when the operational question is really about node-adjacent workloads rather than the node OS itself.
+
+## References
+
+- The gap is tracked as a feature request in the upstream project backlog; ask your platform security contact for the current target release.
+- For scope-related usage patterns, consult the Container Security extension documentation shipped with your ACP install (the `security_and_compliance` section under `docs/en/security/`).