Causely's Approach to Platform Security

Causely places a premium on security. Here is the security architecture of our causal AI platform.

Causely 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.

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.

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

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.

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.

Conclusion

Causely’s security measures ensure that the causal AI platform operates optimally and securely while minimizing any risks to customer data.

Contact us to learn more about Causely and our approach to security.

Related Resources

• Learn about Causely’s causal AI platform for IT
• Check out Causely for cloud-native applications
• Request a demo to see Causely in action