Documentation Under Development

We're busy documenting the
Icebreaker Technical Reference.


Contact us for early access!

Tell us how to reach you.

Security

Icebreaker runs inside your VPC — your sensitive data stays there, and nothing connects back in.

Problems with Conventional Data Platforms

  • Inbound network access into your VPC, or your data shipped out to a vendor-hosted service.
  • Broad IAM roles that give the vendor's compute direct access to confidential, proprietary, and personally identifiable information in your tables — including your own customers' data, if you run a multi-tenant service.
  • Blind trust that their shared, multi-tenant control plane keeps your workloads isolated from everyone else's.

Every Icebreaker query runs in its own isolated pod inside your cluster. The execution engine itself lives in your VPC, so your query content and results are never uploaded anywhere for us to process.


The Icebreaker Agent connects out to our control plane — never the other way around. There's no inbound port to open, and no direct access to your data to hand over.

Key Concept • 2 Min Read

Trust, But Verify

Most vendors ask you to trust their internal controls. Icebreaker gives you something to check instead. Verification isn't hard — most of the claims below take minutes to confirm from inside your own cluster — and it buys you real accountability, lower risk, and full transparency, not just our word for it. We separate the control plane (hosted by Icebreaker) from the data plane (your cluster, your data): only metadata crosses that boundary — instance definitions, capacity policy configuration, and operational status like pod health and replica counts.



1. Your data never crosses the boundary, because it never has to leave.
This isn't just a policy about what we upload or export. The execution engines that actually run your queries are ephemeral pods that live inside your own cluster — see Query Isolation for how that works. Query content, intermediate state, and results are produced and consumed entirely within your VPC. There's no export step to trust, because there's no execution happening anywhere else — Icebreaker never has direct access to your sensitive data, or to the data of the tenants and customers you serve.


2. The connection is outbound-only.
The Icebreaker Agent in your cluster initiates a single outbound connection to the control plane. The control plane never initiates a connection into your cluster — there's nothing for it to reach even if it wanted to.


3. Access is least-privilege.
The Agent's Kubernetes permissions are scoped to the namespace you designate for Icebreaker workloads. The only cluster-wide access it holds is for capacity policy resources, which by nature aren't namespaced in Kubernetes.


4. Query results stay local too.
Results are delivered from your query executor pods back to the Data Server over Redis — deployed by the Icebreaker Agent inside your own cluster, next to the Data Server itself, never in Icebreaker's control plane. If your team is wary of caches because you don't trust where they live, the same principle applies here: nothing about your query results is ever sent anywhere outside your cluster.



On the roadmap

Connecting Icebreaker to your Iceberg catalog currently means providing catalog and storage credentials, which are stored in the control-plane database. We recommend scoping those credentials to the minimum permissions Icebreaker needs and rotating them regularly. We're rolling out support for IRSA / Pod Identity so this step can be removed entirely — no static keys stored anywhere.

Trust You Can Verify

Not policy promises — properties of the architecture itself.

01

Outbound-Only, Zero Inbound Access

The "how" of connecting without exposing your cluster.

  • The Icebreaker Agent opens a single outbound connection from your cluster to our control plane.
  • Nothing ever connects inbound to reach your cluster — no firewall rule to open, no exposed endpoint to defend.
  • If the connection drops, the Agent simply reconnects. Your workloads keep running either way.
02

Least-Privilege Kubernetes Access

The "what" of what we're allowed to touch.

  • The Agent's permissions are scoped to the namespace you choose for your workloads.
  • Cluster-wide access is limited to the handful of resources capacity management actually needs.
  • You can inspect the exact RBAC rules yourself — nothing is a black box.
03

Encrypted Everywhere, Your Identity

The "who" of getting in and staying protected.

  • Every connection — Agent to control plane, browser to console — runs over TLS.
  • Sign-in goes through Google OAuth. Icebreaker never sees or stores your password.
  • Enterprise identity providers (Entra ID, SAML, OIDC) are on the roadmap.

Have questions specific to your environment? Talk to our team or read the FAQ.