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
Add a flag (possibly --sensitive or --hide-sensitive) which would obfuscate any potentially sensitive data in the result outputs.
Enabling this flag would either hide the sensitive data completely (i.e. token 'eyJhbGciOiJSUzI1NiIs...' would become '******'), or partially hide it by showing the first n chars (i.e. 'eyJhbGciOiJSUzI1NiIs...' would become 'eyJhbG******').
Why is this needed
The vulnerability results output includes potentially sensitive data in some cases which would be exposed when kube-hunter runs.
For example issue KHV050 (Read access to pod's service account token) displays the full token in the 'evidence' field.
In most scenarios this token was previous relatively sensitive, however this scan output would now expose this token as plaintext in the kube-hunter logs.
Say you're a developer who doesn't have access to retrieve this token by any means, but you have access to get logs from a pod. Now you have access to something you shouldn't by reading these logs.
The text was updated successfully, but these errors were encountered:
What would you like to be added
Add a flag (possibly
--sensitive
or--hide-sensitive
) which would obfuscate any potentially sensitive data in the result outputs.Enabling this flag would either hide the sensitive data completely (i.e. token 'eyJhbGciOiJSUzI1NiIs...' would become '******'), or partially hide it by showing the first n chars (i.e. 'eyJhbGciOiJSUzI1NiIs...' would become 'eyJhbG******').
Why is this needed
The vulnerability results output includes potentially sensitive data in some cases which would be exposed when kube-hunter runs.
For example issue KHV050 (Read access to pod's service account token) displays the full token in the 'evidence' field.
In most scenarios this token was previous relatively sensitive, however this scan output would now expose this token as plaintext in the kube-hunter logs.
Say you're a developer who doesn't have access to retrieve this token by any means, but you have access to get logs from a pod. Now you have access to something you shouldn't by reading these logs.
The text was updated successfully, but these errors were encountered: