kubectl and helm do in your terminal: through the proxy in HTTPS_PROXY, HTTP_PROXY and NO_PROXY, trusting the certificate authorities your computer trusts. Usually there’s nothing to set.
The proxy
On macOS and Linux, apps opened from the Dock or a launcher don’t get what your shell profile sets. So as Lumovi starts, it asks your login shell for its proxy, as it asks for itsPATH: HTTPS_PROXY, HTTP_PROXY and NO_PROXY, each in upper case or lower case. A variable already set where Lumovi starts, from launchctl setenv or a terminal, is kept. On Windows, apps get your account’s environment variables: set them as in Setting environment variables.
Your organization can set the proxy for every Lumovi on its computers instead, in its policy: that one is used, whatever your shell says.
HTTPS_PROXY is for https addresses, and HTTP_PROXY for http ones (upper case first, when both are set). A proxy without a scheme, like proxy.corp.example.com:3128, is taken as http://, as curl takes it; one that isn’t a URL at all is left out, and Lumovi says so as it starts, in a notice titled “Lumovi started without something it was given”. Through it go:
- Your clusters, unless the cluster names a proxy of its own, with
proxy-urlin your kubeconfig: that one is used instead, askubectlwould. Aproxy-urlcan be anhttp,httpsorsocks5proxy. - Helm: Artifact Hub, and the repositories whose charts Lumovi lists. The
helmit runs, and your credential plugins, get the same variables. - Terminals’ matching kubectl, from dl.k8s.io or your organization’s mirror, trusting the same certificate authorities.
- This computer:
localhost,127.0.0.1and::1([::1]), where your port forwards and AI assistants are, whateverNO_PROXYsays. Other addresses in127.0.0.0/8aren’t left out unlessNO_PROXYnames them. - What
NO_PROXYleaves out, a list separated by commas or spaces, read the same way for everything Lumovi connects to:
Looking for new versions of Lumovi is different: it goes through the proxy your system’s network settings name, as a browser does (a PAC file too), not your shell’s. Where your organization’s policy names a proxy, it goes through that one, unless the policy’s
noProxy is *. It trusts your system’s certificates either way, not the policy’s caFiles.
A proxy that wants credentials takes them in its URL: http://user:password@proxy.corp.example.com:3128. Lumovi leaves them out of what it says. The policy’s proxy gets its credentials only when it asks for them itself, at its own address and port: never another proxy, or a site, that asks.
Certificate authorities
A proxy that inspects HTTPS signs what it passes on with a certificate authority of your company’s, which IT installs on your computer. Lumovi trusts what your computer trusts, besides the public authorities it comes with:- macOS: the certificates trusted in Keychain Access.
- Windows: the certificate store.
- Linux: the system’s certificates, like
/etc/ssl/certs.
certificate-authority (or -data) is the only one its connection trusts, as with kubectl.
helm and credential plugins check certificates themselves, most of them against the system’s certificates. When the policy names certificate authorities, Lumovi gives them SSL_CERT_FILE too, a file with all it trusts, which Go programs like helm read on Linux. On macOS and Windows, they read only the system’s: install the authority there.
When it doesn’t connect
A cluster that can’t be reached shows why on the start screen: hover its label. For a certificate, the label is Certificate error, and it says which:
A proxy that refuses the connection shows as Unreachable, saying so: “The proxy needs credentials (407): give them in its URL, as
http://user:password@host:port.”, or “The proxy didn’t open a tunnel (it answered 403).” when it won’t let the connection through.
Helm says the same of Artifact Hub and chart repositories, after Couldn't reach and the address.
Connecting clusters
Where clusters come from, and what each status means.
Policy for your organization
The proxy, certificates and more, set by IT for every computer.