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.
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 Reasoning 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 our Causal Reasoning Platform
- Check out Causely for Cloud-Native Applications
- Watch our demo to see Causely in action
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.