kubel--can-get-namespace: Avoid spurious warning

[akanouras]

Hello and thank you for your work!

The resolution of issue #38 did not help me as a new user - being a K8S newbie and having just installed minikube/kubectl v1.19.4 and kubel, I couldn't understand why no namespaces were listed, as kubel-use-namespace-list was set to auto and kubectl --context minikube auth can-i list namespaces did return yes\n in its stdout after all.

By using --all-namespaces, this warning disappears while still allowing kubel--can-get-namespace to fail on other kubectl stderr warnings.

This pull request does not address the separate issue of kubectl get namespaces not working even after kubectl can-i returned yes\n, but I think it does increase the chances of the user getting a namespace list out of the box.

Feel free to reject in any case!

[abrochard]

Hi, thank you very much for submitting this. I am not 100% on top of the namespace story here and I would need to do some research to understand what's going on. Would you be able to explain or point me to a resource that could explain why --all-namespaces is better?

[p4v4n]

@akanouras @abrochard Also facing the same issue.

Fixed it on my local by replacing equal with s-suffix? but as you mentioned in the previous issue the output of 'can-i' cannot be trusted completely.

Using --all-namespaces will also fix this for my current env but might cause a issue if the role doesn't have access to all namespaces.
(I'm using a clusterrolebinding without any namespace limitations. Maybe the warning occurs only in this scenario?)

[abrochard]

@p4v4n thank you for chiming in there.

My design goal here is to have 3 possible values for kubel-use-namespace-list: auto, on, off. The last two are simple, they're user overrides. For auto, the intent is to try to automatically figure it out. However, if auto thinks that the user can list namespaces and it turns out that the user cannot (false positive case), the experience is going to be broken and some errors are going to be thrown. On the other hand, if auto thinks that the user cannot list namespaces and it turns out that the user can (false negative case), the experience is diminished but not broken and the user can always set an override.

It's for that reason that I want to understand a bit more what --all-namespaces does and if there's a risk of false positive. I'm more comfortable with keeping the false negative rate relatively higher in comparison.

[p4v4n]

@abrochard
Thanks for quick response and for clarifying the design decision. Makes sense that you want to avoid false positives.
Didn't check kubel-use-namespace-list clearly before. Will use this from now on.

Regarding --all-namespaces haven't found any clear documentation on the difference in kubectl can-i list context except for this 1 comment.
kubernetes/kubernetes#85869 (comment)