You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The token should be redacted for security or only visible at a certain level of logging (eg: debug / verbose)
Comments
We ship our logs out to an external ELK server and support multi-tenancy for both ELK and k8s. As a result, anyone who has ELK access can see our admin service account.
I see value in the logs containing the token if you're troubleshooting, but I don't think it should be the default. A solution could be to accept an argument for the level of logging or change the log file path destination outside of the container logs getting shipped to ELK.
The text was updated successfully, but these errors were encountered:
I have same issue with this, and exposes greater security for someone with less privileges to be able to elevate the or impersonate admin login.
Yes there is a way for to lock it down and exclude it from being logged to services such as ELK, Splunk, Sumo etc.. however it is in best practice for any sensitive data such as usernames, passwords etc be retracted from logs.
Environment
Steps to reproduce
cat /var/log/containers/kubernetes-dashboard* | grep token
Observed result
You can see the full token stored in the logs
Expected result
The token should be redacted for security or only visible at a certain level of logging (eg: debug / verbose)
Comments
We ship our logs out to an external ELK server and support multi-tenancy for both ELK and k8s. As a result, anyone who has ELK access can see our admin service account.
I see value in the logs containing the token if you're troubleshooting, but I don't think it should be the default. A solution could be to accept an argument for the level of logging or change the log file path destination outside of the container logs getting shipped to ELK.
The text was updated successfully, but these errors were encountered: