Skip to main content

Security

Overview​

Causely installs in seconds using automatic instrumentation. Existing observability tools can be used as data sources. Causely ensures that sensitive data or personally identifiable information (PII) remains within customer's environment, and minimizes the transfer of data to its SaaS backend. This data primarily encompasses the service topology and detected symptoms such as high service latency or high CPU utilization. All data is encrypted both in transit and at rest. Access to the Causely infrastructure is strictly restricted to a select group of personnel responsible for operating the service.

The raw source data, such as metrics and logs, is processed locally, retained in the customer's environment and not transmitted to the SaaS backend. Causely doesn't use the customers data to train a foundational model, there is no training data that would be used across customers. At Causely, we believe the key to solving these challenges lies in abstraction; a purposeful approach to reasoning about cause-and-effect relationships in complex systems. Abstraction is the foundation of our approach to service reliability. 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​

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.