We started Karrots with a security-first mindset:

• Use an isolated sub-account of your main account
• Do not hold customer secrets
• No direct access to customer environments
• Built environments follow the Zero-Trust security model
• Isolated developer and production environments
• Gitops: no environment changes outside of git
• Resist cascading failures

It all starts with the domain name

We chose a “dot-app” domain name because the registrar, Google, enforces HSTS preload for all dot-app domains for all browsers. It is not possible to reach karrots.app without TLS. This defends against person-in-the-middle attacks you might not see. No action you take will allow you to reach us unencrypted.

The total fail scenario

Because we manage data platforms for many companies, we assume we are an ongoing, valuable target and have challenged ourselves to come up with a design where a total compromise of our own systems does not allow the attacker to reach any of our customers’ systems. The way we do this comes in two parts:

We do not hold customer secrets

All secrets needed to manage and operate customer environments live inside the customer’s cloud account secrets manager. While of course we isolate and encrypt our database, a compromise of that database would give the attacker nothing about our customers’ systems.

We cannot initiate actions against your accounts

We create no external accounts, tokens or keys to access your environments. Instead, we set up environments to use what’s called IAM role-chaining. The idea is simple: your environment trusts an AWS Cognito identity provider that identifies us to your environment so that we can assume a role in that environment. That role has no capabilities. We then use that role to ask permission to assume our internal management role. The internal management role is only assumable by our jump role and is totally within your control. We provide the option to require a hardware key 2FA to assume that management role. If you enable this behavior, we cannot assume that role without a WebAuthn hardware key challenge. Because this 2FA comes from your account, you control it. You manage these hardware keys — we can’t see or change them. If you lose or swap a key, it’s a simple matter for your IT/devops to fix it from your cloud account console.

So how do we apply patches and make updates to your account if we don’t have that hardware key? We don’t! Instead, we send you a notification of a pending action for your environment, and you initiate that action from our UI. During the interaction you perform the hardware key WebAuthn challenge to allow us to assume the management role. We cannot initiate any operations against your environment!

Securing the customer environment

We set up your environments to trust your corporate IDP (Google Workspace, AWS Cognito, Okta, etc). We then configure the open-source products we install in your environment to use that IDP to give your employees access. Moreoever, we provide access to internal services such as your data warehouse via rotating OIDC temp-tokens generated from your corporate IDP based on the service account underlying the tool the user logged into (e.g. Jupyter).

There are no passwords or tokens to access your internal data or systems: Redshift, Postgres/Mysql, BigTable and so on. If you remove a user from the corporate IDP they immediately lose access to the environments and the data. And because our model is Zero Diff all data access is from cloud operations and never stored on the local laptop.