Description
What happened?
Setup all helm installed:
- ingress-nginx-4.12.1 appver - 1.12.1
- oauth2-proxy-7.12.8 appver - 7.8.2
- kubernetes-dashboard-7.11.1
dashboard ingress:
kong:
admin:
tls:
enabled: false
app:
ingress:
enabled: true
ingressClassName: nginx
issuer:
name: letsencrypt-prod
scope: cluster
tls:
secretName: dashboard-tls
annotations:
nginx.ingress.kubernetes.io/auth-signin: "https://auth.fp.mydomain.com/oauth2/start?rd=$scheme://$host$request_uri"
nginx.ingress.kubernetes.io/auth-url: "https://auth.fp.mydomain.com/oauth2/auth"
nginx.ingress.kubernetes.io/proxy-buffer-size: "64k"
nginx.ingress.kubernetes.io/auth-response-headers: "Authorization,X-Auth-Request-User,X-Auth-Request-Email,X-Auth-Request-Access-Token,X-Auth-Request-Groups,X-Auth-Request-Preferred-Username"
nginx.ingress.kubernetes.io/configuration-snippet: |
auth_request_set $name_upstream_1 $upstream_cookie_name_1;
access_by_lua_block {
if ngx.var.name_upstream_1 ~= "" then
ngx.header["Set-Cookie"] = "name_1=" .. ngx.var.name_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
end
}
hosts:
- k8s-dash.fp.mydomain.com
I can see from wireshark that the Authorization header is being passed to the dashboard pods but I still see the login page after the calls.
The below is post oauth2-proxy authentication, a call from the kong pod to the dash api service.
Frame 632: 4247 bytes on wire (33976 bits), 4247 bytes captured (33976 bits) on interface unknown, id 0
Linux cooked capture v2
Internet Protocol Version 4, Src: 10.64.2.20, Dst: 34.118.231.200
Transmission Control Protocol, Src Port: 46908, Dst Port: 8000, Seq: 4506, Ack: 2681, Len: 4175
Hypertext Transfer Protocol
GET /config HTTP/1.1\r\n
Via: 1.1 kong/3.8.0\r\n
Host: kubernetes-dashboard-web:8000\r\n
Connection: keep-alive\r\n
X-Forwarded-For: 10.10.0.8, 10.64.1.4\r\n
X-Forwarded-Proto: https\r\n
X-Forwarded-Host: k8s-dash.fp.mydomain.com\r\n
X-Forwarded-Port: 443\r\n
X-Forwarded-Path: /config\r\n
X-Real-IP: 10.64.1.4\r\n
X-Kong-Request-Id: 07b3507945ec995472b72268669f7b33\r\n
[truncated]Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6ImM3ZTA0ND ....
X-Auth-Request-User: 112793030068346651797\r\n
X-Auth-Request-Email: [email protected]\r\n
[truncated]X-Auth-Request-Access-Token: ya29.a0AZYkNZhwcDeKiY9iFU2khm2ItxytllvY_1Hmpd2bxnVnEIyJLN-....
X-Request-ID: 4801a450a6e238461bc930b86698c8bd\r\n
X-Forwarded-Scheme: https\r\n
X-Scheme: https\r\n
X-Original-Forwarded-For: 174.53.109.141\r\n
cf-ray: 92c4dcfafe8832ed-JAX\r\n
sec-ch-ua-mobile: ?0\r\n
accept-encoding: gzip, br\r\n
cf-ipcountry: US\r\n
priority: u=1, i\r\n
accept-language: en-US,en;q=0.9\r\n
cf-visitor: {"scheme":"https"}\r\n
referer: https://k8s-dash.fp.mydomain.com/\r\n
sec-fetch-dest: empty\r\n
cf-connecting-ip: 174.53.109.141\r\n
sec-fetch-mode: cors\r\n
sec-fetch-site: same-origin\r\n
cdn-loop: cloudflare; loops=1\r\n
sec-ch-ua-platform: "Linux"\r\n
user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36\r\n
accept: application/json, text/plain, /\r\n
sec-ch-ua: "Chromium";v="134", "Not:A-Brand";v="24", "Google Chrome";v="134"\r\n
[truncated]cookie: _oauth2_proxy=comL0zZR_tWbL5Q5yhYo4E58ihoalHx...
Cookie pair [truncated]: _oauth2_proxy=comL0zZR_tWbL5Q5yhYo4E58ihoalHxLE...
\r\n
[Full request URI: http://kubernetes-dashboard-web:8000/config]
What did you expect to happen?
I expected the login screen to be bypassed.
How can we reproduce it (as minimally and precisely as possible)?
Instructions above
Anything else we need to know?
No response
What browsers are you seeing the problem on?
No response
Kubernetes Dashboard version
7.11.1
Kubernetes version
❯ kubectl version Client Version: v1.32.3 Kustomize Version: v5.5.0 Server Version: v1.31.6-gke.1020000
Dev environment
No response