Product guide
Ownership, access, and operations control
Organization/project ownership, tasks, roles, storage, identity, and audit scope for multi-team use.
Control plane
- Organization, project, and repository ownership
- Durable task state, progress, retries, and failure records
- Six fixed roles and resource-scoped access policy
- Audit, package-usage, operation, and outbound logs
- LDAP, Google, generic OIDC, and API tokens
- Selectable support bundles and platform-diagnostics guidance for System Admins
Ownership and authorization model
Organization provides the top ownership scope, project provides working context, and repository provides the package-access boundary. Fixed roles govern platform functions, while access policies bound to user, group, or anonymous subjects restrict actions on resources.
Task and record surfaces
Long-running work produces durable task state, progress, retry, and failure summaries. Audit records administrative changes, Package Usage records package requests, Operation records background work, and Outbound records external-system access for distinct purposes.
- Owner, start and finish time, status, counters, and error summary for each critical task
- Actor and resource scope on the audit record for each administrative change
- Reconciliation of package access with Package Usage and, where applicable, the firewall decision
- Outbound or Operation evidence that separates external-connection failure from user error
Task visibility and support bundles
The sidebar shows running-task counts separately and in aggregate for Intelligence, Scan Evaluation, Risk Acceptance, and Cleanup and Storage domains visible to the user. From Support, a System Admin can download selectable record sections for the latest seven-day window as a ZIP; a manifest and sanitized health snapshot are mandatory in every bundle.
- Counts refresh every 30 seconds, cap visually at 99+, and omit a domain when its query fails; they do not replace alerts or task detail.
- Runtime, application, operation, outbound, audit, and package-usage sections are selected as needed; download is disabled when none is selected.
- Runtime and database records pass through a second secret-redaction layer before entering the ZIP; the response uses no-store and nosniff headers.
- A bundle does not grant the vendor remote cluster access. Administrators must review the archive under organizational data-sharing policy before release.
- Pod scheduling, image-pull, OOMKilled, or pre-application-logging crash evidence belongs to the cluster; kubectl, oc, or Rancher guidance must be applied separately.
Enterprise responsibility boundary
The platform provides role and record mechanisms, but identity-provider lifecycle, group ownership, log retention, task intervention, and secret rotation must be defined by the adopting organization. Published scope does not claim certification or automatic compliance with a specific regulation.