Swift pushes container inventory to a central ACS scanner and tests policies before rollout

Swift has described an OpenShift security architecture that avoids polling hundreds of clusters from a central database. Instead, agents in each cluster send container-image inventory to object storage, where a central job queries Red Hat Advanced Cluster Security for Kubernetes and returns a prioritized, ownership-aware risk profile to the configuration management database.

The financial messaging cooperative presented the design at Red Hat Summit 2026; Red Hat published the architectural account on Aug. 21. The pattern matters to platform teams because it separates distributed inventory collection from centralized vulnerability analysis while keeping the central layer rebuildable from code.

Push inventory instead of polling clusters

Swift’s earlier problem was the network and operational cost of a central configuration management database reaching into every cluster for vulnerability data. The replacement reverses that flow.

A local agent gathers image information from each OpenShift environment and writes it to a shared object store. A stateless scanning job then uses one ACS Central instance to match those images against known CVEs. The pipeline enriches findings with ownership information from Git before sending the prioritized results back to the database used by security teams.

This design reduces direct central-to-cluster connections and gives the platform team a recoverable control plane. Red Hat says deleting a cluster does not strand critical state because the central components can be reconstructed from code and the inventories are repopulated by the remaining agents.

Test policy noise before production

Swift also treats security-policy changes like application releases. Before promoting an ACS upgrade or policy change, the team runs it against sandbox workloads designed to trigger known violations. The regression pipeline checks that the expected alerts appear before the change advances through development, test and production.

That step targets a familiar failure mode in platform security: a policy may be technically correct but generate enough false positives or unexpected blocks to disrupt developers. Known-good trigger workloads give the security team a repeatable baseline for detecting that drift before the policy reaches production clusters.

What platform teams can borrow

The reusable lesson is not Swift’s scale claim; it is the split between collection, enrichment and action. Cluster-local collectors report what is running. A central scanner adds vulnerability context. Git metadata identifies the owning team. The configuration database becomes the place where prioritized work is consumed, not the system that performs fleet-wide discovery itself.

Red Hat says Swift runs daily scans that include short-lived pods and uses Argo CD with HashiCorp Vault for certificate management. Other operators should validate the data-retention, freshness and failure semantics of their own implementation, but the architecture offers a concrete route to reducing cluster polling and policy alert fatigue without decentralizing the security decision model.