Skip to main content

Security

Overview​

Causely installs in seconds using lightweight automatic instrumentation. It integrates seamlessly with your existing observability stack. Metrics, traces, and logs remain in your environment and can be used as data sources for causal analysis.

Causely is designed to protect sensitive data and ensure privacy. Personally Identifiable Information (PII) and raw telemetry data, including metrics, logs, and traces, remain within your environment by default. Causely processes this data locally and only transmits minimal, high-level information to its SaaS backend, such as service topology and observed symptoms (for example high latency or CPU usage). All data is encrypted in transit and at rest.

To provide context around inferred root causes, Causely may send a targeted subset of telemetry, such as relevant metrics, traces, and log-derived errors/events, to the backend after a root cause is identified. This data is used solely to enhance the clarity and usefulness of the root cause view.

Causely’s infrastructure is strictly access-controlled. Only a small, authorized operations team has access, and customer data is never used to train any shared or foundational models. Each customer’s causal graph is built and maintained independently, based on their specific service topology and behaviors, ensuring both privacy and accuracy.

Our approach is rooted in abstraction: modeling cause-and-effect relationships in complex systems. The causal graph is dynamically created by combining the abstract causal model with the discovered topology uniquely for each customer and maintained automatically and continuously. It enables us to cut through complexity, deliver precise insights, and build trust through transparency and actionable outcomes.

Architecture​

Mediation​

The mediation comprises four components installed into a customer's Kubernetes cluster. As a default, all components operate with minimal privileges needed.

Agents​

Agents are deployed as a Kubernetes Daemonset across all nodes in the cluster to gather node and container level metrics. This necessitates the following permissions:

  • The container runs as privileged (securityContext.privileged=true)
  • The container runs as root (securityContext.runAsUser: 0)
  • The container readonly mounts the host filesystem into the container, granting access to the host directly (volumeMounts.readOnly: true)

This is required as the Causely agent leverages eBPF technology, which necessitates privileged access. Additional Kubernetes API permissions are required to collect specific metrics about the node and containers.

Agents don't establish any outbound connections to the internet or any other service apart from the Mediator and VictoriaMetrics. The agents periodically forward the topology and manifestation data to the Mediator, which, in turn, sends it to the Causely SaaS backend for analysis.

Agent Architecture​

Agent Architecture

Mediator​

The Mediator is installed as a Kubernetes Deployment and is responsible for collecting cluster-level metrics and transmitting the data to the SaaS backend. The Mediator listens in-cluster for OpenTelemetry signals (port: 4317) and updates from the agents (port: 50051).

The Mediator has only the minimal permissions necessary to discover the local cluster configuration and collect metrics.

The Mediator can also be optionally configured to get metrics from Prometheus or discover and monitor managed cloud services from the cloud providers.

Executor​

The Executor is responsible for executing remediation actions within the cluster, and its Kubernetes ServiceAccount is granted the cluster-admin role.

The Executor is an optional component and can be enabled as part of the deployment process.

VictoriaMetrics​

VictoriaMetrics is a timeseries database used by the agents and mediator (port: 8428) to store additional timeseries data.