Security controls

This page summarizes the controls built into the product. Most are on by default; the ones you configure link to their settings.

Sign-in and access

• Single sign-on with your identity provider over OIDC, with your groups mapped to roles. A built-in local admin is available for first setup or installs without SSO, and an open mode for trusted networks. See Authentication.
• Three roles: viewer (read), editor (change alert rules, channels, dashboards and pipelines), admin (access, retention, backups, upgrades). See Access & roles.
• Sessions are signed cookies, marked Secure (serve the portal over HTTPS), and expire after 12 hours by default (queryApi.auth.sessionTtl).
• Login lockout and rate limits per client address. Behind a load balancer, list it in queryApi.auth.trustedProxies so the real client address is used and can’t be forged.
• API tokens for scripts and CI carry a role and an expiry. Only a fingerprint is stored, so a token can’t be read back. A revoked token stops working on every replica within 30 seconds, and a token can’t create other tokens.

Audit trail

Sign-ins, failed sign-ins, every configuration change, every denied request, token use, AI write-ups, AI agent tool calls and approved fixes are recorded with who, what, when, the client address and the outcome. Admins can search it on the Audit page, and it’s kept for 365 days by default (schemaInit.auditRetentionDays), separately from telemetry retention.

Changes to your cluster

Actions, such as restarting or rolling back a workload, are off by default. When on:

• Each runs as the person who approved it, with the token their identity provider issued. Your Kubernetes API checks it against your own RBAC, and your cluster’s audit log names them.
• The product itself has no Kubernetes permissions to make changes. It can act only with the token of a person who is approving a change at that moment, never on its own.
• A fresh sign-in is required before any change (within 15 minutes by default), and access tokens can be revoked as soon as each action is verified.
• Automated fixes from runbooks are proposed for a person to approve, and are checked again against the live cluster before they run.

Encryption in transit

• Remote sites connect to the core over mutual TLS, with certificates from a certificate authority built into your install. A site’s identity comes from its verified certificate, never from what it says about itself, and certificates can be revoked or a site decommissioned from the portal, effective within a minute. See Connecting remote sites.
• The portal is served over HTTPS through your ingress, with your certificate.
• Traffic between the core’s own components is encrypted by default: the sensor and collectors to the ingest gateway, the portal to the API, and the API and gateway to the database, enrollment and the lifecycle manager. Each server presents a certificate from a certificate authority built into your install, and each client verifies it. A site’s own sensor and collectors reach its connector the same way. If you run cert-manager, it can issue and renew these certificates instead, from your own certificate authority if you like. See Internal TLS.
• Unencrypted connections are still accepted by default on the same ports, so applications and collectors already sending to the core keep working. Turn that off (internalTLS.allowPlaintext: false) once everything sending to the core uses TLS.
• With replicated storage, the database replicas copy data between each other over TLS, and need a password to do it; their coordination service (Keeper) is reached over TLS, and its members talk to each other over TLS.

Encryption at rest

Telemetry, configuration and backups are stored on volumes and storage you provide, so they’re encrypted the way your storage class or bucket is.

Least privilege inside the product

• Each component has its own database user with only the grants it needs. The ingest gateway can only insert telemetry (and read two configuration tables). The API can read, and write only its own configuration and state tables, with no rights to drop or alter tables. Backups, restores and retention changes, all admin-only in the portal, use a separate administrative connection.
• Secrets stay out of the database. Notification channels store the name of a Kubernetes Secret key, never the webhook URL or password. Model API keys come from Secrets too.
• Containers run as non-root on minimal distroless images, apart from the sensor, which needs kernel access (see Sensor permissions) and drops every capability it doesn’t use.
• Outbound connections are guarded: notification targets can’t reach the core’s loopback or cloud metadata endpoints, and synthetic checks and the lifecycle manager can be fenced with optional NetworkPolicies.

Data minimization

• SQL literal values are replaced with ? before spans are stored.
• Query strings are removed from captured URLs.
• Prompt and response text is removed from language-model spans at ingest, whichever library sent them.
• AI write-ups and agents can be set to leave log lines out (queryApi.ai.redactLogs).
• You set retention per data type on the Retention page.

How we build releases

• Every image and chart is signed, with a CycloneDX SBOM and SLSA build provenance, all verifiable offline. See Verifying signed artifacts.
• Builds use pinned toolchain versions.
• Every Go module is scanned with govulncheck every week, and on every pull request that changes dependencies.
• Upgrades through the lifecycle manager deploy only releases whose signature verifies against the key built into your install, by digest, and roll back automatically if the new version doesn’t come up healthy.