Bearer token not working

[sefaYavuz]

What happened?

When creating a bearer token using the provided example on the login page:

kubectl -n NAMESPACE create token SERVICE_ACCOUNT

I get the following error: GET http://35.207.138.93:9090/api/v1/me 500 (Internal Server Error)

Looking at it in the auth logs i can see the following:

[GIN] 2024/03/14 - 13:13:18 | 500 |       82.39µs |     10.244.0.12 | GET      "/api/v1/me"
[GIN] 2024/03/14 - 13:13:30 | 200 |       49.38µs |     10.244.0.12 | GET      "/api/v1/csrftoken/login"
[GIN] 2024/03/14 - 13:13:30 | 200 |    2.299741ms |     10.244.0.12 | POST     "/api/v1/login"
[GIN] 2024/03/14 - 13:13:30 | 500 |       48.77µs |     10.244.0.12 | GET      "/api/v1/me"
E0314 13:13:30.444532       1 handler.go:33] "Could not get user" err="MSG_LOGIN_UNAUTHORIZED_ERROR"

What did you expect to happen?

To be able to login with the created bearer token

How can we reproduce it (as minimally and precisely as possible)?

I did nothing special other then adding a external ip to the kong gateway so i can access it from the browser without port-forward.

Anything else we need to know?

No response

What browsers are you seeing the problem on?

Chrome

Kubernetes Dashboard version

7.1.2

Kubernetes version

Client Version: v1.28.0 Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 Server Version: v1.28.3

Dev environment

No response

[T-Lakshmi]

/kind support

[floreks]

Can you check if api/v1/me request from your browser contains Authorization: Bearer <token> header? It somehow looks like header is not there and /me endpoint cannot validate user.

[sefaYavuz]

You are correct it doesn't.

GET /api/v1/me HTTP/1.1
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cache-Control: no-cache
Host: ip:9090
Pragma: no-cache
Proxy-Connection: keep-alive
Referer: http://ip:9090/
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36

[floreks]

I don't know what but something on your side must be dropping headers from the request. Another option is that token size somehow exceeds 4kB and is too big, but this should not be the case when using SA token.

[floreks]

That's either a configuration issue or a duplicate of #8794

/close

[k8s-ci-robot]

@floreks: Closing this issue.

In response to this:

That's either a configuration issue or a duplicate of #8794

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[darmbrust]

For anyone else running into issues with the bearer token... The UI is not sending the bearer token to the /me endpoint, if you have your ingresses configured in such a way that you are trying to access it via http instead of https.

The UI just silently doesn't send the token, and then displays a 401 error about the token being invalid. In reality, the UI shouldn't even present the bearer token login page when it doesn't allow it to function of http - and provide a more proper error message.

I was doing some proof-of-concept testing in a complicated network where its not easy to get https setup for a proof of concept... and discovered this rather user-unfriendly handling... after way to much digging trying to figure out why all of the simple-as-can-be examples didn't work....

[petergithub]

You are a saver. The UI is not sending the bearer token if access it via HTTP.

For anyone else running into issues with the bearer token... The UI is not sending the bearer token to the /me endpoint, if you have your ingresses configured in such a way that you are trying to access it via http instead of https.

The UI just silently doesn't send the token, and then displays a 401 error about the token being invalid. In reality, the UI shouldn't even present the bearer token login page when it doesn't allow it to function of http - and provide a more proper error message.