Security & privacy

Putting production credentials on a phone deserves a straight explanation of where they go and what talks to what. Here it is.

There is no server in the middle

Kubo connects directly from your device to the endpoint you configure — your API server, your broker, your bucket. There is no Kubo backend, no relay, no proxy, and no account to create.

Two consequences worth knowing:

• Reachability is yours to control. If an endpoint is not reachable from your device’s network, the app cannot reach it either. That is the point.
• Nothing is collected. No telemetry about your cluster contents, no logs shipped anywhere, no analytics on what you looked at.

Credentials live in the platform keystore

Tokens, passwords, API keys, client certificates and CA bundles are written to the operating system’s secure storage — the iOS/macOS Keychain, the Android Keystore-backed store, and the platform equivalents on desktop. Non-secret metadata (a connection’s name, URL, namespace) is stored separately as ordinary settings.

Secrets are never written into bookmarks, history or screenshots, and the app syncs them nowhere.

One credential, many connections

Credentials are managed centrally and referenced by connections, so the same secret can back more than one:

• one AWS key pair for an EKS cluster and an S3 bucket;
• one internal CA for every internal endpoint;
• one bearer token for Prometheus and Traefik.

You can list, edit and delete them from a single screen — and deleting a credential is one action, not a hunt through connections. More detail on Access, auth & credentials.

Authentication, per system

Native EKS auth

EKS clusters normally authenticate through an exec plugin that shells out to the AWS CLI — which cannot exist on a phone. Kubo instead builds the same token aws eks get-token produces: a SigV4-presigned STS request, computed on device and refreshed as it expires. Static keys, temporary credentials and assume-role are all supported, and Kubo can fetch a cluster’s endpoint and CA for you when you add it.

Private clusters over Tailscale

The most common way to reach a cluster with no public endpoint: run the Tailscale Kubernetes operator and point Kubo at the API-server proxy’s tailnet hostname. Authentication is your tailnet identity — often with no credential stored in the app at all — and the cluster stays entirely private.

TLS

Every connection can carry its own CA certificate, so internal and self-signed PKI works without weakening anything globally. Client certificates are supported for Kubernetes. There is an insecure/skip-verify option for connections that need it — deliberately per connection, never a global default, and never the pre-selected choice in a form.

Least privilege

Kubo asks for nothing beyond what a screen needs, and degrades cleanly when it is refused:

• cannot read events → the tab explains that, everything else keeps working;
• no metrics-server, or no access → usage and charts are simply absent;
• cannot read the CoreDNS ConfigMap → service hostnames fall back to cluster.local, and the app tells you it is assuming rather than knowing.

A read-only service account gives you a read-only app. Every destructive action — delete, scale, restart, purge, force-close, suspend — sits behind a confirmation that names what it is about to affect. Manifests are read-only, and the kubectl console has no apply, edit or exec in its grammar at all.

See what it sends

A built-in network console records the HTTP calls the app makes, including the ones the kubectl console generates. If you would rather verify than trust, you can watch the traffic before you point Kubo at production.

What leaves your device

Only the requests you cause, to the endpoints you configured — plus the presigned S3 URLs you explicitly choose to create and share, which are generated on device with your own credentials and expire on the schedule you pick.

That is the whole list. See also the privacy policy.