Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle known permission errors by default #18

Closed
yuvalavra opened this issue Jun 6, 2021 · 2 comments · Fixed by #20
Closed

Handle known permission errors by default #18

yuvalavra opened this issue Jun 6, 2021 · 2 comments · Fixed by #20

Comments

@yuvalavra
Copy link

yuvalavra commented Jun 6, 2021

Kubelets that enforce authorization have known responses for permission errors. For example, if a request is authenticated but isn't authorized, the Kubelet will respond with: Forbidden (user=%s, verb=%s, resource=%s, subresource=%s)

kubeletctl currently prints a generic error message for permission errors, so it can be hard to understand what's causing the error:

$ kubeletctl --token=<token> pods
[*] Failed to run HTTP request with error: invalid character 'F' looking for beginning of value

The actual error can be seen using --raw, but if you're not using kubeletctl regularly it's easy to forget about that. It would be awesome if kubeletctl could check whether a response is a known permission error, and if so print the full error by default.

Kubelet responses for permission errors

  • Unauthenticated request or Authentication error - http.StatusUnauthorized (401), Unauthorized
  • Unauthorized request - http.StatusForbidden (403), Forbidden (user=%s, verb=%s, resource=%s, subresource=%s)
  • Authorization error - http.StatusInternalServerError (500), Authorization error (user=%s, verb=%s, resource=%s, subresource=%s)
@g3rzi
Copy link
Contributor

g3rzi commented Jun 8, 2021

Thanks @yuvalavra for the suggestion and the elaboration, I think it's a good idea.
We will have a look on that and update accordingly.

@g3rzi
Copy link
Contributor

g3rzi commented Sep 8, 2022

Hi @yuvalavra we added a small fix for that issue that will now print the errors with details.
It should be generic for any errors, we were able to verify it on 401 and 403.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

3 participants