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.
What would you like to be added
Add a flag (possibly
--sensitiveor--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.