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 | Runs bounded DNS, TCP and HTTP checks through the authenticated agent channel using the read access already declared by the chart. It does not create a diagnostic pod. |
| Write validation | Off | Where explicitly supported and enabled, proposed changes are evaluated with server-side dry runs. A dry run does not persist the change. |
The standard collector role contains no Kubernetes create, update, patch or delete verbs. Optional pod-log access adds only get on pods/log. Review the rendered chart RBAC before installation because enabled feature flags determine the final permission set.
Generated fixes remain review-first. KrevoPilot does not autonomously apply a recommendation to a customer cluster.
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.
Slack and Microsoft Teams notifications
Administrators can scope a destination by team, cluster, event type and minimum severity, and configure repeat intervals, quiet hours and weekly digests. A notification destination does not grant product or cluster access.
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 derives the tenant from the authenticated session, never from an untrusted tenant identifier supplied by the browser. Workspace roles control allowed actions; team and direct cluster grants control which clusters a member can see.
- 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.
- An unassigned Viewer or Developer receives no implicit cluster visibility.
- Cross-tenant and cross-cluster 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 and direct grants map members to permitted clusters.
- OIDC group mappings can assign Viewer, Developer or Admin, but never Owner.
- Password sign-in can remain available during SSO testing.
- An Owner recovery path should remain available before SSO is required.
- Audit records attribute material actions to the authenticated user.