Privacy and security

Lumovi has no telemetry and no accounts. It doesn’t send anything about you or your clusters anywhere you didn’t ask it to.

​

What it connects to

The desktop app talks to:

• The clusters in your kubeconfig, with the credentials in it.
• The Prometheus or VictoriaMetrics you use for usage history, reached through the cluster’s API server with your own credentials. Nothing is port-forwarded or exposed for it.
• Artifact Hub, only when you search it for a chart to install.
• The chart repositories and registries you choose, when you upgrade or install a Helm release from one.
• GitHub, to look for new versions of Lumovi. Help → Check for Updates Automatically turns that off.

That’s all. Links to anything else, like a release’s notes, open in your browser.

​

Your credentials

Kubeconfig credentials stay in the app’s main process: tokens, client keys and the output of credential plugins. The page you see never has them. Every request to a cluster is made by the main process, after it checks what the page asked for. Lumovi reads your kubeconfig and never changes it. Managing kubeconfig files, like adding contexts or signing in to a cloud provider, is left to the tools made for it.

​

How the app is built

• The page is sandboxed. It runs with context isolation, no Node.js integration and a strict Content Security Policy. It can’t navigate away or open new windows.
• Every request is checked. The main process only answers calls from the app’s own page, and validates every argument.
• No browser permissions. The page can’t use the camera, notifications or anything else a website could ask for. It can only copy to the clipboard.
• Changes go through a small set of operations. Each is checked against what you’ve made read-only, and refused for those clusters, or for all of them with LUMOVI_READ_ONLY. See Read-only mode.
• Links are limited. Only https:// links, and http://localhost:<port> for your own port forwards, are handed to the operating system.
• Updates are verified. New versions come from the project’s GitHub releases over HTTPS. Each download is checked against the SHA-512 checksum the release lists, and on macOS the new version must carry the same Developer ID signature.

The source is on GitHub, so you can check any of this. Every release’s installers come with checksums and signed build provenance: see Verify your download.

​

Secrets on screen

Lumovi is careful with what it shows:

• Lists of Secrets carry only the names of their keys. Values are blanked before they reach the page.
• Values stay hidden until you reveal them. An open Secret shows each key with its size, and •••••••• for its value. Reveal one key, or all of them, when you need to. Copying a value works without revealing it.
• The YAML is hidden too. The YAML tab hides values until you choose Reveal values, and so does the last-applied-configuration annotation, which holds a copy of them.

See Config and storage for how Secrets are shown and edited.

​

What it keeps on your computer

The desktop app keeps two kinds of things on your computer, and none of it leaves it:

• Settings, in settings.json: your theme, the window’s size and place, which clusters you made read-only, where each one’s usage history comes from, and whether Lumovi looks for new versions by itself.
• Conveniences the page remembers: the namespace you picked per cluster, your recent clusters, the kinds you pinned to the sidebar and the custom resources you opened last, the detail panel’s width, the time range metrics charts open with, and which chart on your computer each Helm release was last deployed from.

Both live in Lumovi’s folder for app data: Lumovi also reads your own views from ~/.lumovi/views, or the folder LUMOVI_VIEWS_DIR names. It never writes there. When you upgrade or install a Helm release, the values go to helm in a temporary folder, which Lumovi deletes as soon as helm is done. The activity log of the changes you made lives in memory, and is gone when you quit.

​

In your cluster

When Lumovi runs in a cluster for a team, people sign in, and it acts with their own permissions. That has its own model: how sign-in works, what its service account may do, and how to keep it locked down. See Security.

​

Reporting a vulnerability

Please report vulnerabilities privately, through a GitHub security advisory or as the security policy describes. Please don’t open a public issue. Include what you found, how to reproduce it, and the impact you expect. You’ll get an acknowledgement within a few days. Security fixes go into the latest release.