From d1fd4073af359ebf9cbd104c603f16e6fd930605 Mon Sep 17 00:00:00 2001 From: Komh Date: Fri, 24 Apr 2026 01:41:02 +0000 Subject: [PATCH] [security] Scoping Collections to node-level assets for vulnerability reporting --- ...evel_assets_for_vulnerability_reporting.md | 60 +++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 docs/en/solutions/Scoping_Collections_to_node_level_assets_for_vulnerability_reporting.md diff --git a/docs/en/solutions/Scoping_Collections_to_node_level_assets_for_vulnerability_reporting.md b/docs/en/solutions/Scoping_Collections_to_node_level_assets_for_vulnerability_reporting.md new file mode 100644 index 00000000..688751da --- /dev/null +++ b/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 == ` 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=, namespace=`. 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/`).