Open michaelmdresser opened 2 years ago
@Adam-Stack-PM FYI. This is a feature request from a hosted customer.
@michaelmdresser, Thanks. I have added the hosted label and will get this considered for an upcoming release cycle. If you want to help move this forward, it would be great if you could add a rough time estimate.
2 days of my time due to familiarity. 3-4 days of someone else's time, in case it gets tricky.
kubectl cost --no-cluster --path "kubecost.example.com"
@teevans @kwombach12 what do you think about prioritizing this soon? With the launch of KC Cloud beta, I suspect this will be an increasingly-important ask.
@michaelmdresser I like this idea. Lets take a look at this in 105.
I've had similar requests for authentication on OpenCost APIs so they could be exposed similarly.
Another user ask for this feature: https://kubecost.slack.com/archives/C052PHJNQ49/p1683578888197519
We need same feature.
In a multi-tenant openshift cluster, generally admins place an oauth-proxy as a sidecar to opencost pod, to grant access to authorized users only.
So, it would be nice to set Authorization: Bearer <TOKEN>
header in addition to direct API URL.
@debMan thanks for bumping this! We are actively looking at solutions here
Problem
Users of Kubecost's hosted product do not have cluster/
kubectl
access to the cluster in which the primary Kubecost instance is running, because Kubecost is hosting that in our internal infrastructure. This means they cannot usekubectl cost
to get cost information because the CLI currently supports two query modes: port-forward and proxy, both of which require cluster access:https://github.com/kubecost/kubectl-cost/blob/dc741c5acd1601fac8dccbacc1d8baeee6c10200/pkg/query/allocation.go#L35-L50
Proposed solution
Implement a new query mode
http
(on top of the current proxy and port-forward) that sends requests directly to a Kubecost HTTP API endpoint without using a K8s client to execute the request.Possible additions
It would be amazing (though probably difficult) to somehow tie the current cluster in the user's Kubeconfig to a cluster ID in Kubecost, enabling intelligent filtering of Kubecost data based on the current Kubeconfig context. This is a step 2 for this request, unless it turns out to be simple. (perhaps we could see if there is a
kubecost
namespace and snag the cluster ID from env vars?)