mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-08-09 18:32:52 +00:00
Anso
2a4955f56d
* feat: add dedicated Security page and policy-pack foundation Bring vulnerability scanning, scan history, suppressions, Compose risks, secrets, policy packs, and scanner setup into one node-scoped Security command center instead of scattering them across Resources and Settings. - New top-level Security view with Overview, Images, Compose risks, Secrets, Policies, Suppressions, History, and Scanner setup tabs (status masthead + signal rail; controlled tabs with deep-link support). - Backend: GET /security/overview rollup and GET /security/policy-packs static catalog (auth-only, Community). DatabaseService gains an uncapped scan-status count and a node-eligible block-policy count, and getImageScanSummaries now projects secret and misconfig counts. - Reuse existing surfaces: the scan-history sheet, the control-governed suppression and acknowledgement panels, and the scan-detail sheet (now with an initial-tab prop so it opens on the matching finding type). - Extract a shared SeverityBadge (from Resources) and a TrivyManager (from Settings) so both surfaces render identical controls. - Resources "Scan history" now links into the Security page History tab. - Docs for the new Security surface and tests for the new endpoints, helpers, nav wiring, and tabs. * refactor: consolidate scanner and policy management onto the Security page Remove the Settings "Vulnerability Scanning" section now that the Security page covers the same ground, with every option preserved: - Scanner install / update / uninstall / auto-update live on the Scanner setup tab (TrivyManager). - Scan policies, the honor-suppressions toggle, and the replica managed-by-control / demote controls move into a new ScanPolicyManager on the Policies tab (paid; Community sees only the policy-pack catalog). - CVE suppressions and acknowledgements remain on the Suppressions tab. Wiring removed: the registry section and the now-empty Security settings group, the SectionId, the SettingsSectionContent case and the isPaid prop it was the sole consumer of, and SecuritySection itself. The dashboard configuration-status "Vulnerability scanning" row now navigates to the Security page Policies tab. Docs that pointed at "Settings -> Security -> Vulnerability Scanning" are swept to the relevant Security page tabs. * fix: harden Security page scanner refresh, policy-load errors, and secret-only badges Address independent-review findings on the Security page: - Scanner setup now refreshes Trivy state when the active node changes, so the displayed scanner status matches the node TrivyManager's actions target (both follow x-node-id). Previously, switching nodes on the tab left stale state. - ScanPolicyManager surfaces an explicit error state on a failed policy fetch instead of falling through to a false "No scan policies configured". - The shared SeverityBadge and the Images findings column no longer label a scan "clean" when it has secrets or misconfigurations but no CVE severity (highest_severity is derived from vulnerabilities only); they show a "Findings" state and the secret/misconfig counts instead. - The Overview enforcement note points to the Policies tab, not the removed Settings section. - The History tab auto-opens the scan-history sheet only on a deep-link (mount with the History tab active), not on every manual tab selection. Adds tests for the badge secret/misconfig state and the policy-load error state.
47 lines
2.1 KiB
TypeScript
47 lines
2.1 KiB
TypeScript
// Free-tier sections are exported eagerly: every operator sees them on every
|
|
// install so static imports keep first-paint fast.
|
|
export { AccountSection } from './AccountSection';
|
|
export { AppearanceSection } from './AppearanceSection';
|
|
export { LicenseSection } from './LicenseSection';
|
|
export { HostAlertsSection } from './HostAlertsSection';
|
|
export { DockerStorageSection } from './DockerStorageSection';
|
|
export { FleetMeshSection } from './FleetMeshSection';
|
|
export { NotificationsSection } from './NotificationsSection';
|
|
export { DeveloperSection } from './DeveloperSection';
|
|
export { DataRetentionSection } from './DataRetentionSection';
|
|
export { AppStoreSection } from './AppStoreSection';
|
|
export { SupportSection } from './SupportSection';
|
|
export { AboutSection } from './AboutSection';
|
|
export { RecoverySection } from './RecoverySection';
|
|
|
|
// Paid-tier sections (UsersSection, WebhooksSection,
|
|
// LabelsSection, CloudBackupSection, NotificationRoutingSection) are NOT
|
|
// re-exported from this barrel. They are dynamically imported with
|
|
// React.lazy in SettingsPage.tsx so their JSX, copy, and prop shapes do not
|
|
// land in the bundle a Community user downloads. Re-adding any of them as a
|
|
// static export here would defeat the split: rollup detects the static path
|
|
// and keeps the module in the main chunk regardless of the lazy() call.
|
|
export { DEFAULT_SETTINGS } from './types';
|
|
export type { PatchableSettings, SectionId, Agent } from './types';
|
|
export {
|
|
SETTINGS_GROUPS,
|
|
SETTINGS_ITEMS,
|
|
getSettingsItem,
|
|
getSettingsGroup,
|
|
isItemVisible,
|
|
isItemLocked,
|
|
} from './registry';
|
|
export type {
|
|
SettingsGroupId,
|
|
SettingsGroupMeta,
|
|
SettingsItemMeta,
|
|
TierGate,
|
|
Scope,
|
|
VisibilityContext,
|
|
} from './registry';
|
|
export { SettingsSection } from './SettingsSection';
|
|
export { SettingsField, type SettingsFieldTone } from './SettingsField';
|
|
export { SettingsCallout, type SettingsCalloutTone } from './SettingsCallout';
|
|
export { SettingsActions, SettingsPrimaryButton, SettingsSecondaryButton } from './SettingsActions';
|
|
export { useMastheadStats } from './MastheadStatsContext';
|