Skip to content
KVNest
Sign in

Security

What we do to protect your instances, and what we don't do yet. KVNest is in preview, so the last section matters as much as the first.

Isolation

  • One namespace per instance.

    Each instance runs in its own Kubernetes namespace, which enforces the Pod Security Admission level restricted and carries a resource quota sized to the plan.

  • Locked-down containers.

    The server runs as a non-root user with a read-only root filesystem, all Linux capabilities dropped and the runtime default seccomp profile. The pod gets no service account token.

  • Fixed resources.

    Requests equal limits, so your memory and CPU are reserved for the instance and not shared with its neighbors (Guaranteed QoS).

  • Closed network.

    A network policy blocks all egress, so an instance can't call out. Ingress is allowed only from the ingress proxy, the metrics scraper and the KVNest operator.

Network and TLS

  • TLS is required.

    Connections use rediss:// on port 6380, routed by SNI to your instance. The certificate is a publicly trusted Let's Encrypt wildcard for *.eu.kvnest.com, so clients need no CA file.

  • IP allowlists.

    Limit an instance to up to 32 CIDR ranges. The proxy checks the real client address, taken from the load balancer's PROXY protocol header, before a connection reaches the server.

  • Hosted in Germany.

    Instances run at Hetzner in Germany, operated by Kubenest, a company registered in Amsterdam.

Access control

  • ACL users.

    Create extra users that are read-only or read-write, each limited to the key patterns you choose. Extra users never get admin commands.

  • A restricted default user.

    The default user can run most commands, but not manage or list ACL users, and not CLIENT KILL or CLIENT PAUSE. Those would expose password hashes or cut off the connections KVNest uses for health checks and metrics.

  • Dangerous commands are off.

    CONFIG, DEBUG, MODULE, SHUTDOWN, REPLICAOF, SLAVEOF, FAILOVER, SYNC and PSYNC are disabled on every instance.

  • No cross-account access.

    Asking for another account's instance returns 404, the same answer as for one that doesn't exist.

Credentials and tokens

  • Hashed passwords.

    Instance passwords are written to the server configuration as SHA-256 hashes, never as plaintext.

  • Rotation without downtime.

    Rotate a user's password and keep the old one working for up to 7 days while you redeploy clients, or end that grace period early.

  • API tokens.

    Only a SHA-256 hash of each token is stored, and the secret is shown once. Tokens can expire after 1 to 365 days, you can hold five unexpired ones, and a token can't create, list or delete tokens: only a signed-in session can.

The hosted MCP server

  • Token required.

    Every request to the MCP server needs one of your API tokens, and it acts only as you.

  • Honest tool labels.

    Tools that only read are marked read-only, and tools that change or remove things are marked destructive, so clients can ask before running them.

  • Deleting needs the name.

    delete_instance refuses to run unless the instance's name is typed again as confirmation.

The website and dashboard

  • Sign in with Google or GitHub.

    KVNest stores no password for your account. The session is a sealed cookie that lasts seven days.

  • Safe redirects.

    After sign-in you can only be sent back to a page in the dashboard or the tutorials, so the login can't be used as an open redirect.

  • Browser protections.

    kvnest.com is served over HTTPS with HSTS for one year, and its pages can't be framed by other sites.

What we don't have yet

  • Single node.

    No replica and no automatic failover. If the node restarts, your instance is down until it is back.

  • No backups during the preview.

    Casual and Pro keep an append-only file that survives restarts, but that is not a backup.

  • No SLA.

    Nothing is guaranteed in writing during the preview.

  • No third-party audit or certification.

    We haven't had an independent security audit, and we hold no SOC 2 or ISO 27001 certificate.

  • No SSO or two-factor of our own.

    Sign-in is Google or GitHub, so your account is as safe as theirs. Turn on two-factor there.

Report a vulnerability

Email security@kvnest.com. The same address is in our security.txt. Please include what you found, the steps to reproduce it, which instance or page is affected (never send passwords or data), and how to reach you.

Please don't access, change or delete other customers' data, and don't disrupt the service. Test against your own instances. We'll read every report and reply, and we'll fix what we can confirm. We don't run a bounty program.