Skip to main content

Data & Integrations

SOC 2 Type II

Signadot is SOC 2 Type II compliant. To request a copy of our latest report, email info@signadot.com.

Data Access and Collection Overview​

Kubernetes Cluster Access​

Signadot has access only to Kubernetes resources permitted by the Operator's Kubernetes RBAC within your cluster. These RBAC permissions are minimal and documented here: Kubernetes Permissions.

  • The Operator and its agents access Kubernetes configuration objects required to create and manage Signadot CRDs and related resources (for example, workloads referenced by a Sandbox, RouteGroup configurations, etc.).
  • Access is used solely to reconcile and operate Signadot resources in-cluster and to surface their state in the Signadot control plane UI and APIs.

Data Transmitted to Signadot SaaS​

By default, Signadot sends only the minimal metadata needed to display and operate your Signadot resources:

  • References to in-cluster resources that the Operator manages (for example, names of workloads, namespaces, image references as strings present in CRDs, and other CRD field values).
  • Operational status and events necessary to reflect the state of Signadot resources.

Additionally, depending on which product features you opt into, the following may be sent:

  • Smart Tests with Smart Diff: If enabled and your HTTP requests are instrumented for traffic capture, request/response data used for diffs may be captured. See Traffic Capture.
  • Traffic Record (CLI streaming): Streams requests/responses from the cluster to your CLI via the Signadot SaaS API, without storing request or response bodies. Minimal metadata relevant to the traffic record system may be logged (routing key, timestamps, HTTP protocol version, method, request URI, related workload) and is subject to our system log retention policy.
  • Signadot Jobs: Logs associated with Signadot Job runs may be collected to enable viewing after execution.
  • Pod logs for Signadot-managed workloads (e.g., Sandbox pods) are streamed through encrypted tunnels to the UI for live viewing and are not persisted by Signadot.

Excluded Data Types​

  • Signadot does not collect contents of container images, application source code, or data from inside your application containers.
  • Aside from optional traffic capture used by Smart Diff, Signadot does not collect request/response bodies or headers from your application traffic.

Data Usage and Processing​

Machine Learning Models for Smart Diff​

When using Smart Tests with Smart Diff, Signadot uses traditional unsupervised learning (statistical methods) to construct request-response models based on traffic that opts into being captured. These models analyze historical request and response data and use statistical methods to model fields and values, enabling noise-filtered comparison between baseline and sandbox traffic.

Models are constructed and trained independently for each organization. Traffic data from one organization is never used to train models for another organization, and models are not shared across organizational boundaries. Each organization's models operate in isolation within that organization's context.

Traffic modeling only occurs when a Smart Test opts into using Smart Diff with traffic capture enabled. If you choose not to use this functionality, no such data is captured, stored, or modeled. Models are used solely for the Smart Diff feature to help identify relevant differences between baseline and sandbox traffic, as described in the Smart Tests documentation.

Encryption​

Signadot uses TLS for all networking in and out of our service including from the browser to our API and from the API to your Kubernetes cluster, and all other points of communication.

Data Storage​

Signadot minimizes storage of identifying information. We do not store API keys or cluster tokens; instead, we store hashed values together with a masked value for display. We no longer store metadata about GitHub pull requests, except in deprecated APIs. We do store references to in-cluster data necessary to operate Signadot resources: the CRDs created and managed by the Signadot Operator and, by extension, the fields in those CRDs that reference in-cluster objects (for example, workload names and image references).

Any information we do store is placed in an encrypted relational database.

Traffic Capture Storage​

When using Smart Tests with HTTP requests instrumented for traffic capture, Signadot stores captured requests and responses in its control plane, encrypted at rest.

For requests, per-hop headers are elided as well as

  • Authorization:
  • Authentication:
  • Cookie:

For responses, the Set-Cookie: header is elided. Models are treated in an encapsulated fashion, so that no information derived from traffic in one organization will be used in another organization. Models are encrypted at rest and only accessible over TLS with authentication.

Job Logs Storage​

When using Signadot Jobs, logs emitted by Jobs may be stored to enable post-run viewing and troubleshooting. These logs are stored in Signadot storage encrypted at rest and are accessible only via authenticated requests over TLS.

Integrations​

Kubernetes​

The minimal required Kubernetes RBAC permissions to function are requested during the installation of the operator. For detailed documentation on the Kubernetes RBAC permissions, refer to Kubernetes Permissions.

Signadot uses helm to install a cluster agent as part of the Signadot Operator on a Kubernetes cluster. This agent connects securely using TLS encrypted TCP tunnels to the Signadot API Server to enable serving authenticated previews over *.preview.signadot.com.