Know exactly what crosses the cluster boundary.
This guide describes the implemented collection, permission and retention boundaries. Optional diagnostics and write workflows are called out separately from normal read-focused collection.
Architecture and trust boundary
The agent initiates outbound communication. KrevoPilot does not require inbound network access to the Kubernetes API.
What is and is not collected
- Cluster, node, workload, pod and readiness metadata
- Resource requests, limits and usage samples
- Kubernetes warning events and status reasons
- Selected, redacted manifests needed for topology and diagnosis
- Agent/chart/image version and connection health
- Kubernetes Secret values
- Service-account bearer tokens
- Unbounded full-cluster log archives
- Arbitrary files from nodes or containers
- Cloud credentials from customer workloads
Identifier privacy can replace resource names with stable one-way aliases. When real-name collection is enabled, the UI can show exact application and object names. Changes to this setting require an identity migration so old aliases and new names are not counted twice.
Agent permission modes
| Mode | Default | Behavior |
|---|---|---|
| Normal collection | On | Uses get and list for Kubernetes discovery, status, metrics, events and enabled manifest context. It has no mutation verbs. |
| Diagnostics | Off | When explicitly enabled, may create and remove a restricted, short-lived diagnostic pod to test DNS, TCP or HTTP from the target namespace. |
| Write actions | Off | When explicitly enabled, supported patch/update operations are server-side dry runs. They do not persist changes. |
“Read-only” describes the normal collection path. Optional diagnostics need create/delete permission for their ephemeral pod. Optional write validation needs dry-run patch/update permission for supported workload kinds. Neither should be enabled without a customer security review.
Write validation excludes Secrets, RBAC objects and custom-resource definitions. Review the rendered chart RBAC before installation because enabled feature flags determine the final permission set.
Live logs, retained evidence and Loki
Loki stays customer-controlled. KrevoPilot queries the configured endpoint within the permitted integration boundary; it does not silently deploy or retain a second copy of all logs.
Default retention schedule
| Data | Default retention |
|---|---|
| Cluster snapshots | 7 days, maximum 10,000 per tenant and cluster |
| Raw resource metrics | 14 days |
| Hourly optimization rollups | 90 days |
| State, events and error fingerprints | 180 days |
| Sanitized investigation evidence | 30 days |
| On-demand redacted pod logs | One-time display, purged within 15 minutes |
| Command metadata | 30 days |
| Local database backups | 14 nightly copies |
Optional object-storage backups need a separately configured lifecycle. Without that lifecycle, the application’s database cleanup cannot delete independent backup copies.
Workspace deletion must remove tenant-scoped live data and follow the documented backup expiry process. Obtain written confirmation for contractual deletion requirements.
Tenant and cluster isolation
Operational records are tenant-scoped in the database. API authorization must derive the tenant from the authenticated session, never from an untrusted tenant identifier supplied by the browser. Cluster access is further narrowed by role and team assignment.
- A customer cannot list another tenant’s clusters, users, investigations, deployments or metrics.
- Cluster keys authenticate only their saved cluster connection.
- Saved deployments and Git connections are workspace-scoped.
- Cross-tenant checks belong in automated backend tests, not only frontend hiding.
Identity, SSO and audit
Owners configure OIDC, allowed company domains, automatic provisioning and optional SSO enforcement. Newly provisioned members receive the configured default role and no cluster access until assigned.
- Roles: Owner, Admin, Developer and Viewer.
- Teams map members to permitted clusters.
- Password sign-in can remain available during SSO testing.
- An Owner recovery path should remain available before SSO is required.
- Audit records should attribute material actions to the authenticated user.