Make k8s-lens-proxy optional (atleast for port-forward and exec)

[jkroepke]

What would you like to be added?

I would like to like to have the ability to disable the k8s-lens-proxy.

A side from "i don't know, why the proxy exists" in general, it causes trouble in context of pod shell and terminal.

Background: I have to reach a private Kubernetes Cluster which is accessible behind a SSH Bastion Jump host.

Instead working with local port forward, I'm using the ssh -D to setup an SOCKS5 proxy. The produces is described here: https://kubernetes.io/docs/tasks/extend-kubernetes/socks5-proxy-access-api/

But this is not compatible with kubectl proxy or with the lens proxy, because I got an error in Lens:

error: unable to upgrade connection: error dialing backend: dial tcp: lookup ..eks.amazonaws.com: no such host

Thats true, because the hostname is only resolvable from the bastion host, but not from the local host.

But invoking kubectl port-forward and kubectl exec outside of Lens works. I also guess there might be an bug in Kubernetes proxy function.

But I see no reasons for using the proxy construct in general.

Ref: https://github.com/kubernetes/kubernetes/blob/122219790f82f5843d99aacbcb3d96162161e027/staging/src/k8s.io/client-go/tools/clientcmd/api/v1/types.go#L87

Why is this needed?

No response

[dex4er]

One topic is if we really need lens-k8s-proxy, and it is rather good question. It simplifies Lens's Kubernetes client as the proxy has own TLS certifiate then the browser can hit the endpoint even if each cluster has separate own certificate.

Anyway: currently proxy is used by kubectl command run from Lens too. It looks like unnecessary complication as kubectl should be able to reach the real endpoint without additional proxy as any other CLI tool. We should make it optional in shell session.

Second is that I never used SOCKS as it blocked SPDY protocol. SPDY is replaced now with Websockets which is 100% compatible with lens-k8s-proxy and any other HTTP proxy. Personally I hide EKS endpoint behind NLB+ALB then my kubectl and lens-k8s-proxy connect to proxy server rather than to EKS endpoint directly.

[jkroepke]

It simplifies Lens's Kubernetes client as the proxy has own TLS certifiate then the browser can hit the endpoint even if each cluster has separate own certificate.

Did you mean the connection between Electron and Kubernetes? I thought Lens is using the Kubernetes SDK which should natively handle that. Or is Lens using basic http clients to invoke calls against the API?

[dex4er]

No, it uses pure Javascript https://github.com/kubernetes-client/javascript library with fetch() function below. So technically it is basic http client which is bundled in Lens as all these libraries are ESM modules and Electron supports only CommonJS then we have https://github.com/freelensapp/freelens/tree/main/packages/transpilation to make this Kubernetes client compatible with Electron.

[jkroepke]

But the

No, it uses pure Javascript kubernetes-client/javascript

But if kubernetes-client/javascript is used, the should take care of kubeconfigs and TLS client certificates.

The downside of the proxy is there is no automatic token refresh, if clusters that works with temporary credentials like EKS, AKS or any other OIDC based authentications does.

[ritzmannk]

i got now the issue with the lens-k8s-proxy. browsing and updating work perfectly but exec and port-fowarding will not work. it will break on creating websocket:

I0610 23:39:22.537166  823140 tunneling_dialer.go:75] Before WebSocket Upgrade Connection...
I0610 23:39:22.537228  823140 round_trippers.go:463] GET https://127.0.0.1:34217/141eb27e7f89d7f649d7be59d1985482/api/v1/namespaces/demis/pods/notification-gateway-6-3-10-b191-9f489784f-kkv4x/portforward
I0610 23:39:22.537244  823140 round_trippers.go:469] Request Headers:
I0610 23:39:22.537262  823140 round_trippers.go:473]     User-Agent: kubectl/v1.31.9 (linux/amd64) kubernetes/8f38003
I0610 23:39:22.537277  823140 round_trippers.go:473]     Authorization: Basic <masked>
I0610 23:39:22.537288  823140 round_trippers.go:473]     Sec-Websocket-Protocol: SPDY/3.1+portforward.k8s.io
I0610 23:39:22.642501  823140 round_trippers.go:574] Response Status:  in 105 milliseconds
I0610 23:39:22.642548  823140 round_trippers.go:577] Response Headers:
I0610 23:39:22.642575  823140 fallback_dialer.go:53] fallback to secondary dialer from primary dialer err: unable to upgrade streaming request: websocket: bad handshake (500 Internal Server Error)
I0610 23:39:22.642642  823140 round_trippers.go:463] POST https://127.0.0.1:34217/141eb27e7f89d7f649d7be59d1985482/api/v1/namespaces/demis/pods/notification-gateway-6-3-10-b191-9f489784f-kkv4x/portforward
I0610 23:39:22.642660  823140 round_trippers.go:469] Request Headers:
I0610 23:39:22.642681  823140 round_trippers.go:473]     X-Stream-Protocol-Version: portforward.k8s.io
I0610 23:39:22.642698  823140 round_trippers.go:473]     User-Agent: kubectl/v1.31.9 (linux/amd64) kubernetes/8f38003
I0610 23:39:22.642717  823140 round_trippers.go:473]     Authorization: Basic <masked>
I0610 23:39:22.748599  823140 round_trippers.go:574] Response Status: 500 Internal Server Error in 105 milliseconds
I0610 23:39:22.748650  823140 round_trippers.go:577] Response Headers:
I0610 23:39:22.748672  823140 round_trippers.go:580]     Content-Type: text/plain; charset=utf-8
I0610 23:39:22.748683  823140 round_trippers.go:580]     X-Content-Type-Options: nosniff
I0610 23:39:22.748697  823140 round_trippers.go:580]     Date: Tue, 10 Jun 2025 21:39:22 GMT
I0610 23:39:22.748707  823140 round_trippers.go:580]     Content-Length: 27
error: error upgrading connection: 

[alxy]

Any update on this one? I have a similar problem operating behind a corporate HTTP proxy. All egress HTTP traffic needs to go through that proxy as it is otherwise dropped by our firewall. The k8s-lens-proxy seems to not obey to the system proxy settings, and also does not use standard environment varibles like HTTPS_PROXY to make its requests. At least that is what I assume since as for me also everything works in freelens except exec and port-forward.

[ddagunts]

This is more of a hack, but I did fix this for my use case (clusters behind HTTP proxies):

Open-Lens/lens@84edd87#diff-2fc51ab8266ad8f0b6d3602969fe181bc82b328594affc81c5754dbc0c18a4c7

The gist is in 'packages/core/src/main/kubeconfig-manager/kubeconfig-manager.ts' but it's storing two sets of KUBECONFIGs for each cluster, one for the proxy as before, and an original KUBECONFIG that can be used for pod exec.

Regarding clusters which require routine token refresh, it's definitely an issue. I think it's possible to write a script which would refresh tokens prior to calling kubectl and then manipulate the kubeconfig "users" section, the "args:" and "command:" option for each cluster. Then in Lens when the cluster is disconnected it would auto-reconnect.. Definitely not convenient and manageable for a large fleet, and invites insecure storage of secrets. Not a solution.

[alxy]

Imho best solution would be if lens Proxy would use system proxy settings for its requests. Not sure If such chain ist supported though...

[ddagunts]

System proxy settings are a global option, so either all of your clusters would need to be behind the same proxy or not. I think it would not be convenient for people who have a mix of clusters behind a variety of proxies (and some without). I think a "per-cluster" setting is better (IIRC it's already there).

It's been a while since I last I looked at this but IIRC it wasn't so simple to extend the lens-proxy due to the protocol change that kubectl performs for exec operations. Maybe with switch to WebSockets it's simpler now.

The original Lens seems to have gone with an approach that avoids their proxy as well so we should consider that for what it's worth:
https://forums.k8slens.dev/t/lens-2025-1-161916-latest-release/5377
"Introduced the ability to bypass the internal proxy for commands such as: Pod/Node shells, Port forwarding, and Helm/Kubectl commands, helping users leveraging services like Tailscale or HAProxy."

[Hyurt]

I ran into this issue as well. I wasn't aware of the fact that OpenLens/Freelens used a proxy

Interesting take from their latest release that they managed to bypass it - so I decided to have a deeper look

I managed have a similar behaviour than Lens and connect through sock5 socket.

This is a example and helped me to discover a bit more about it:

• OpenLens/Freelens use a custom kubeconfig (echo $KUBECONFIG in freelens terminal shows a custom path with a custom file pointing to the internal proxy)
• Overriding the command sent my pod-shell helped to bypass this
• My solution for now only work if context is in default ~/.kube/config (I am on macOS - linux should be fine but I don't know for Windows)

If I manage to have some time in November I may try to make a pull request embedding those change but I'll need some help to make it more generic

I made the change within pod-shell-menu.tsx

/**
 * Copyright (c) Freelens Authors. All rights reserved.
 * Copyright (c) OpenLens Authors. All rights reserved.
 * Licensed under MIT License. See LICENSE in root directory for more information.
 */

import { Pod } from "@freelensapp/kube-object";
import { withInjectables } from "@ogre-tools/injectable-react";
import os from "os";
import React from "react";
import { v4 as uuidv4 } from "uuid";
import { App } from "../../../extensions/common-api";
import createTerminalTabInjectable from "../dock/terminal/create-terminal-tab.injectable";
import sendCommandInjectable, { type SendCommand } from "../dock/terminal/send-command.injectable";
import hideDetailsInjectable, { type HideDetails } from "../kube-detail-params/hide-details.injectable";
import activeKubernetesClusterInjectable from "../../cluster-frame-context/active-kubernetes-cluster.injectable";
import type { KubernetesCluster } from "../../../common/catalog-entities";

import PodMenuItem from "./pod-menu-item";

import type { Container, EphemeralContainer } from "@freelensapp/kube-object";

import type { DockTabCreateSpecific } from "../dock/dock/store";

export interface PodShellMenuProps {
  object: any;
  toolbar: boolean;
}

interface Dependencies {
  createTerminalTab: (tabParams: DockTabCreateSpecific) => void;
  sendCommand: SendCommand;
  activeKubernetesCluster: { get: () => KubernetesCluster | null };
  hideDetails: HideDetails;
}

const NonInjectablePodShellMenu: React.FC<PodShellMenuProps & Dependencies> = ({ object, toolbar, createTerminalTab, sendCommand, activeKubernetesCluster, hideDetails }) => {

  if (!object) return null;
  let pod: Pod;

  try {
    pod = new Pod(object);
  } catch (ex) {
    console.log(ex);

    return null;
  }

  const containers = pod.getRunningContainersWithType();
  const statuses = pod.getContainerStatuses();

  const execShell = async (container: Container | EphemeralContainer) => {
    const containerName = container.name;
    const kubectlPath = App.Preferences.getKubectlPath() || "kubectl";
    const activeCluster = activeKubernetesCluster.get();
    const kubeConfigContext = activeCluster?.spec.kubeconfigContext ?? "";

    // By default, the terminal is set up to use the freelens-k8s-proxy. We want to bypass that for `kubectl exec`.
    const commandParts = [kubectlPath,'--kubeconfig','~/.kube/config', `--context`, kubeConfigContext, "exec", "-i", "-t", "-n", pod.getNs(), pod.getName()];

    if (os.platform() !== "win32") {
      commandParts.unshift("exec");
    }

    if (containerName) {
      commandParts.push("-c", containerName);
    }

    commandParts.push("--");

    if (pod.getSelectedNodeOs() === "windows") {
      commandParts.push("powershell");
    } else {
      commandParts.push('sh -c "clear; (bash || ash || sh)"');
    }

    const shellId = uuidv4();

    createTerminalTab({
      title: `Pod: ${pod.getName()} (namespace: ${pod.getNs()})`,
      id: shellId,
    });

    sendCommand(commandParts.join(" "), {
      enter: true,
      tabId: shellId,
    }).then(hideDetails);
  };

  return (
    <PodMenuItem
      svg="ssh"
      title="Shell"
      tooltip="Pod Shell"
      toolbar={toolbar}
      containers={containers}
      statuses={statuses}
      onMenuItemClick={execShell}
    />
  );
};

export const PodShellMenu = withInjectables<Dependencies, PodShellMenuProps>(NonInjectablePodShellMenu, {
  getProps: (di, props) => ({
    ...props,
    createTerminalTab: di.inject(createTerminalTabInjectable),
    activeKubernetesCluster: di.inject(activeKubernetesClusterInjectable),
    sendCommand: di.inject(sendCommandInjectable),
    hideDetails: di.inject(hideDetailsInjectable),
  }),
});

[robertobandini]

Hello everyone, and thank you for your interest and contribution.
What do you think of @Hyurt's solution?