Security

Security is a top priority

Causely places a premium on security

Our Causal Reasoning Platform minimizes the transfer of data to its SaaS backend and retains most of the data within the customer environment. This primarily encompasses the service topology and detected symptoms such as high CPU utilization. The raw source data, such as metrics and logs, are retained in the customer’s environment and are not transmitted to the SaaS backend.

Causely has achieved SOC 2 Type II compliance.

Here is our SOC 3 report.

For more information about our SOC 2 report or to discuss our approach to security, contact us.

SaaS backend

Causely does not store or process any sensitive data or personally identifiable information (PII) that may be available in the customer cluster. 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.

Mediation

The mediation comprises four components installed into a customer’s Kubernetes cluster. None of these components access any sensitive information such as Kubernetes secrets. As a default, all components operate with minimal privileges, including non-root user status, absence of privilege (securityContext.privileged=false), no hostPath mounts, and no access to the Kubernetes API, unless stated otherwise in subsequent sections.

Agents

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

  • The container runs as privileged (securityContext.privileged=true)
  • The container uses root as user
  • It mounts the host filesystem into the container, granting access to the host directly

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 do not establish any outbound connections to the internet or any other service apart from the Mediator and Victoria Metrics. The agents periodically forward the topology and manifestation data to the Mediator, which, in turn, sends it to the Causely SaaS backend for analysis.

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

rules:

– apiGroups: [“”]

resources: [“services”,”nodes”, “nodes/metrics”]

verbs: [“get”, “watch”, “list”]

– nonResourceURLs:

– /metrics

– /metrics/cadvisor

verbs:

– get

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. Specific permissions are necessary to collect cluster-level metrics.

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

rules:

– apiGroups: [“”, “apps”, “app.k8s.io”, “batch”]

resources: [“pods”, “nodes”, “services”, “events”, “deployments”, “replicasets”, replicationcontrollers, “jobs”,

“cronjobs”, “statefulsets”, “daemonsets”]

verbs: [“get”, “watch”, “list”]

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 disabled as part of the deployment process.

Victoria Metrics

Victoria Metrics is a timeseries data used by the agents and mediator to store additional timeseries data.

Contact us

We’d love to hear from you! Reach out with any questions, ideas, or to learn more about how we can help.