The Cloud Panda

Security

We will hand strangers root on Kubernetes clusters. Isolation is the product, so we design for it first.

Reporting a vulnerability

If you think you've found a security problem in thecloudpanda.com, email security@thecloudpanda.com. Please include what you found, how to reproduce it and what an attacker could do with it. Our security.txt has the same contact details.

What we promise

  • To confirm we've received your report within three working days.
  • To keep you updated while we investigate and fix, and to tell you when it's fixed.
  • To credit you publicly once it's fixed, if you'd like that.
  • Not to take legal action against good-faith research that follows the rules below.

Rules for good-faith research

  • Don't access, change or delete other people's data. If you reach any by accident, stop, and tell us.
  • No denial of service, load testing, spam or social engineering of anyone.
  • Give us reasonable time to fix a problem before you talk about it publicly. We suggest 90 days.

Out of scope

  • Reports from automated scanners without a demonstrated impact.
  • Missing best-practice headers or settings without a demonstrated impact.
  • The services of our hosting and email providers themselves: report those to the provider.

When the labs open, this policy will extend to labs.thecloudpanda.com, including breaking out of your own lab environment. We don't run a paid bug bounty.

This website

  • A static site with no JavaScript, no cookies and no requests to third parties.
  • A strict Content-Security-Policy that forbids inline scripts and styles, plus HTTPS-only (HSTS) and the usual hardening headers.

How the labs are designed

The lab platform is being built. This is how it is designed; before the labs open, we will update this page with what we have verified, including the results of an independent penetration test.

  • A virtual machine boundary, not just containers. Each lab cluster runs in its own microVMs (Firecracker), each with its own Linux kernel. Students' clusters never run as Pods in a shared Kubernetes cluster.
  • A private network per session. A cluster's nodes can reach each other, our package and image mirror and our content server. They cannot reach other students' labs, our internal services, any cloud metadata endpoint or the general internet.
  • Limits on everything. CPU, memory and disk are capped per VM, and every session has a maximum length and an idle timeout.
  • Nothing to steal inside. Lab VMs hold no credentials for our systems. Images and manifests come from our own mirror, never from the internet at lab time.
  • Short-lived by default. A lab environment, including everything you typed into it, is deleted when the session ends.
  • Accounts without passwords. Sign-in by emailed link or passkey, with rate limits and CSRF protection. Personal data will be stored in the EU.