通过 k8s 代理访问 Grafana API
Accessing the Grafana API through k8s proxy
我是 运行 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
的替代品,所以我希望在这里找到建议的替代品
我试图在 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
捕获 Pod 中具有 tcpdump -vvvs 0 -l -A -i any
的请求产生了以下结果:
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
header(导致 401 Unauthorized
)所以基本上 API 服务器似乎去掉了这个HTTP header 将请求向下传递到 Pod。
如果我改为使用 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 中发现了这个问题,引用其中一条评论:
this is working as expected. "proxying" through the apiserver will not get you standard proxy behavior (preserving Authorization headers end-to-end), because the API is not being used as a standard proxy
这基本上意味着 kubectl proxy
在尝试通过它进行授权时将不起作用,它不是 "regular" 反向代理并且可能有充分的理由不会保留 Authorization
headers.
请注意,尽管上面使用了基于令牌的身份验证,但我使用 curl
测试了令牌和基本授权。
希望这能让事情更清楚一些!
我是 运行 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
的替代品,所以我希望在这里找到建议的替代品
我试图在 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
捕获 Pod 中具有 tcpdump -vvvs 0 -l -A -i any
的请求产生了以下结果:
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
header(导致 401 Unauthorized
)所以基本上 API 服务器似乎去掉了这个HTTP header 将请求向下传递到 Pod。
如果我改为使用 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 中发现了这个问题,引用其中一条评论:
this is working as expected. "proxying" through the apiserver will not get you standard proxy behavior (preserving Authorization headers end-to-end), because the API is not being used as a standard proxy
这基本上意味着 kubectl proxy
在尝试通过它进行授权时将不起作用,它不是 "regular" 反向代理并且可能有充分的理由不会保留 Authorization
headers.
请注意,尽管上面使用了基于令牌的身份验证,但我使用 curl
测试了令牌和基本授权。
希望这能让事情更清楚一些!