我正在使用基本身份验证在kubernetes中运行Grafana v6.2.4。我想使用k8s代理进行测试(即kubectl proxy --port=8080
)。我已将GF_SERVER_ROOT_URL
环境变量更改为:
{
"name": "GF_SERVER_ROOT_URL",
"value": "http://localhost:8080/api/v1/namespaces/my-namespace/services/grafana-prom:80/proxy/"
}
这使我可以通过http://localhost:8080/api/v1/namespaces/my-namespace/services/grafana-prom:80/proxy/
上的浏览器登录并使用Grafana。
但是,我想通过API使用它。如果我向http://localhost:8080/api/v1/namespaces/my-namespace/services/grafana-prom:80/proxy/api/dashboards/db
发送请求,我会回来的
{
"message": "Unauthorized"
}
但是,如果我设置了一个kubernetes端口转发并将相同的请求发送到http://localhost:30099/api/dashboards/db
,那么它将成功。
除了GF_SERVER_ROOT_URL
之外,是否还有其他环境变量需要更改,以便API服务器根通过k8s代理(即http://localhost:8080/api/v1/namespaces/my-namespace/services/grafana-prom:80/proxy/api/dashboards/db
)通过?我看过here,但找不到。
否则,通过k8s代理访问API的正确方法是什么?
我还要补充一点,我专门尝试使用kubetctl proxy
作为kubectl port-forward
的替代项,因此我希望在这里https://stackoverflow.com/a/45189081/1011724
答案 0 :(得分:2)
我试图在minikube
中复制它,我可能已经找到未正确授权您通过API服务器代理(使用kubectl proxy
进行请求的原因。
运行以下curl
-命令:
curl -H "Authorization: Bearer <TOKEN>" http://localhost:8080/api/v1/namespaces/my-namespace/services/grafana-prom:80/proxy/api/dashboards/home
并使用tcpdump
在tcpdump -vvvs 0 -l -A -i any
中捕获Pod中的请求会产生以下结果:
GET /api/dashboards/home HTTP/1.1
Host: localhost:8080
User-Agent: curl/7.58.0
Accept: */*
Accept-Encoding: gzip
X-Forwarded-For: 127.0.0.1, 192.168.99.1
X-Forwarded-Uri: /api/v1/namespaces/my-namespace/services/grafana-prom:80/proxy/api/dashboards/home
此GET
请求没有Authorization
标头(导致401 Unauthorized
),因此基本上,API服务器似乎在将HTTP标头传递给请求时将其剥离。吊舱。
如果我改为使用kubectl port-forward -n my-namespace svc/grafana-prom 8080:80
,则GET
请求现在看起来像这样:
GET /api/dashboards/home HTTP/1.1
Host: localhost:8080
User-Agent: curl/7.58.0
Accept: */*
Authorization: Bearer <TOKEN>
在写此答案时,我在k / k仓库#38775中发现了这个问题,以评论其中的一条评论:
这按预期工作。通过apiserver进行“代理”不会获得标准的代理行为(端到端保留Authorization标头),因为该API并未被用作标准代理
这基本上意味着kubectl proxy
在尝试通过它进行授权时将不起作用,它不是“常规”反向代理,并且可能出于充分的原因不会保留Authorization
标头。
请注意,尽管上面使用了基于令牌的身份验证,但我同时使用curl
测试了令牌和基本授权。
希望这可以使事情变得简单起来!