Allow skipping resources which are not accessible with current permission
princerachit opened this issue · 10 comments
@ahmetb mentioned in one of his comment about introducing --ignore-inaccessible
#9 (comment)
I find this very useful feature as most of the users don't have access to prod env resources and the tree command just explodes.
In additional, there’s another kind of failure: When some API groups don’t respond with success (for reasons other than authorization).
We may lump these behaviors all into this one flag so that we don’t distinguish between failure modes.
Also we currently query all objects in all namespaces for child objects. In a secure env, a developer won’t have access to all namespaces.
So when we print warnings for inaccessible resources, would we print them per namespace (which can be hundreds of lines per mamespace), or would we just say “Some objects could not be queried and may be excluded from this result”. I am not certain.
Damn I did not read your comment and started working on a PR. Anyway it is a WIP @ahmetb
@princerachit I'm not as interested in code as I'm interested in designing the experience for now. :) Right now this is a design problem to me. It seems like many users will hit this, so I'm looking at solving it the cleanest way.
Sounds right @ahmetb . Another issue I can see is that it takes huge amount of time when running against an enterprise grade cluster
I0106 13:19:41.260134 50748 query.go:45] all goroutines have returned in 7m53.641176705s@princerachit let's open a new issue, I'd love to see full logs and which API groups and how many namespaces etc are involved.
Maybe another design challenge is to include/exclude only a set of resources. As a user it does not make sense to iterate over non - useful resources like snapshots/monitoring/...
@ahmetb Let me talk to my employer. I am not sure if I am allowed to share the logs. But will open an issue.
Sure thing. You can probably redact PII like namespaces, object names, and maybe even API names etc.
The -v 5 logs have enough information to understand how much time is spent while querying an api group. That should be a good place to start.
I also suspect two other things: Something wrong with pagination logic (we can increase page size if it has a lot of objects) and client-side rate limit/burst (both set to 1000 qps right now).
Some objects could not be queried and may be excluded from this result”
What about the default behavior will just print this, and if you want more verbosity, you increase the loglevel, and then get a list of all objects that couldn't be fetched? I would love to use this tool within our company, and propagate it's use, but due to these restrictions it's currently not feasible.
(We, for example, don't have permission to list k8s secrets, because the list verb not only shows the metadata, but gives you actually permissions to view the content of it as well)