403 Forbidden with system:anonymous using Kind cluster and @kubernetes/client-node 1.0 with Bun 1.1.29

[jbiskur]

Describe the bug
When using the client, load from default works to load, I get all the configurations and contexts. If I switch to a non-kind cluster it works. But when I try to access a kind cluster i get this error:

error: HTTP-Code: 403 Message: Unknown API Status Code! Body: "{\"kind\":\"Status\",\"apiVersion\":\"v1\",\"metadata\":{},\"status\":\"Failure\",\"message\":\"nodes is forbidden: User \\\"system:anonymous\\\" cannot list resource \\\"nodes\\\" in API group \\\"\\\" at the cluster scope\",\"reason\":\"Forbidden\",\"details\":{\"kind\":\"nodes\"},\"code\":403}\n" Headers: {"audit-id":"8faa772b-0a02-4a11-a4d0-1ddda79052a9","cache-control":"no-cache, private","content-length":"256","content-type":"application/json","date":"Thu, 09 Jan 2025 22:13:50 GMT","x-content-type-options":"nosniff","x-kubernetes-pf-flowschema-uid":"447ed637-32cb-4e79-9fe9-7007b399d374","x-kubernetes-pf-prioritylevel-uid":"b292a39e-9771-4796-ad28-0c0f74ac00d7"} code: "403"

using kubectl it works, with the same selected context. And as described earlier, using any other cluster works fine. It does not matter what version of k8s is chosen. I have tried with 1.27, 1.32 and 1.29.12 version of kind, I get the same error.

Client Version
e.g. 1.0.0

Server Version
e.g. 1.27, 1.32, 1.29.12

To Reproduce

1. install bun
2. create index.ts file
3. initialize a kubernetes client loading from default.
4. create core api client and list nodes
5. install kind & create kind cluster
6. run the ts file

Expected behavior
To get a 200 response with data for the nodes in the cluster

Example Code

const k8s = new KubeConfig()
k8s.loadFromDefault()
const apiClient = k8s.makeApiClient(CoreV1Api)

const nodes = await apiClient.listNode()
console.log(nodes)

Environment (please complete the following information):

• OS: MacOS 15.1.1
• Bun version: 1.1.29

Additional context
I tried the same with the client version 0.22.3 using the same code, same cluster same everything except the npm package and that works as expected

[brendandburns]

Can you try it outside of bun there were other issues with bun reported:

#1451

[brendandburns]

Can you also send a redacted copy of your kubeconfig file

[jbiskur]

tried with deno, I get the same, works with AKS and EKS clusters and the kind cluster gets a 403.

I had to run deno with --unsafely-ignore-certificate-errors option, like bun and node have to run with the NODE_TLS_REJECT_UNAUTHORIZED=0 env/option

[jbiskur]

redacted kubeconfig

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <*****>
    server: https://127.0.0.1:53896
  name: kind-dedicated-configurator-test
contexts:
- context:
    cluster: kind-dedicated-configurator-test
    user: kind-dedicated-configurator-test
  name: kind-dedicated-configurator-test
current-context: kind-dedicated-configurator-test
kind: Config
preferences: {}
users:
- name: kind-dedicated-configurator-test
  user:
    client-certificate-data: <*****>
    client-key-data: <*****>

[brendandburns]

That kubeconfig file should work just fine.

Can you try running it just as node some/file.js without any of the package managers/whatever in the picture?

Based on the error, I think that the client certificate and/or key are not being sent with the request and my guess is that they are being swallowed somehow inside of how bun is choosing to handle HTTPS certificates.

Either that or it has something to do with how kind is creating the client certificates.

The system:anonymous in the error message means that the Kubernetes API server has no identity information for your requests at all.

[jbiskur]

I think it has something to do with the migration to node-fetch, as the prior to v1.0 it works with the exact setup. I will try with some node project later

[brendandburns]

@jbiskur thanks for the additional details, there was this other issue reported:

#1509

But that had to do with bearer token auth vs. certificate auth. Can you validate that your kind kubeconfig isn't using bearer tokens?

[jbiskur]

yea it is the out of the box configuration, so no bearer token authentication

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned