At Kelda we understand that you place great trust in us to run your containers in the Kelda Development Cloud. We take the security of Blimp extremely seriously and work hard to make sure our infrastructure is safe and secure.
Your containers are run on Kubernetes in Google Cloud Platform data centers in located in the USA.
Your containers are isolated in their own Kubernetes namespace. All of your containers run on a single VM and as a result, no inter-container communication crosses the Google network. A single Blimp VM may run multiple user’s sandboxes. Care is taken to ensure these sandboxes are fully isolated from one another.
All traffic to and inside of Blimp is secured and encrypted with SSL/TLS.
We reserve the right to change the underlying infrastructure of Blimp at any time.
Services used and data stored in them
We use the following services to run Blimp:
Let’s Encrypt to generate certificates for the Blimp container registry.
- Usage of the Blimp CLI including what CLI commands are executed.
- Warnings and errors emitted by Blimp.
- Attempts to use features that are currently not supported by Blimp.
- Standard server-side monitoring and analytics including things like CPU/RAM usage.
The Blimp website uses the following additional services.
Blimp uses Auth0 to implement login and user management. When you login to blimp, we collect an OAuth token from Auth0 that we use to authenticate you with the Kelda Development Cloud. Your username, password, or third-party login credentials are stored with Auth0 and never stored on Kelda’s servers.
How does Blimp access my Containers?
Containers you request for your Blimp sandbox are pulled from the specified
container registry directly into the Kubernetes VM on which they run.
Container. When you specify a
build command in your
the container is built locally using Docker, then pushed to a secure
private container registry operated by Kelda before being pulled onto the
Kubernetes VM on which they run.
Containers and container images never leave the Kubernetes VM on which they run. Blimp does not store, track, analyze or otherwise read container images or contents beyond what’s directly necessary for Kubernetes to boot and run them.
How does Blimp access my Docker Compose file?
We recognise that docker compose files may container sensitive information, so we take their security very seriously.
Your Docker Compose file is sent to the Kelda Development cloud to help it decipher what containers, volumes, and other features you need in your Blimp Sandbox. Once your Sandbox has been created, your Docker Compose file is deleted. Blimp does not store your Docker Compose file or use it for anything other than creating your sandbox.
Does Blimp access my source code?
The Blimp CLI and Blimp infrastructure do not access your source code. However, certain configurations of Blimp may result in your source code being sent to your Blimp Sandbox.
If your container image contains your source code, it will be run in the Blimp Sandbox, and subject to the security and privacy policies for containers described above.
If you use a host bind volume to mount your source code into a container, that code will be sent from your laptop to that container over an encrypted TLS connection. Beyond using Syncthing to perform the file transfers, Blimp does not read the source code.
What if I prefer not to use the Kelda Development Cloud?
We are working on an on-prem version of Blimp that runs on your Kubernetes cluster in your infrastructure. If this is of interest, contact us.