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
Currently, the terraform deployment step results in the hpcadmin SSH key being stored in cleartext in the volume of the deployer, which allows for lateral movement in the network.
It would be preferable to use a local key management solution, such as password-protected (encrypted) SSH keys with an SSH agent and a timeout for ssh-add (e.g. 24h).
The text was updated successfully, but these errors were encountered:
This was flagged by an automatic security scanner of a customer.
I think the basic premise is simply that storing SSH keys in cleartext (time-unlimited token) on a web server allows an attacker who gains access to the machine to move laterally through the network and should be avoided.
Thinking a bit more about this, I guess in the case of a compromise of the deployer VM, the main worry is actually the (permanent) system managed identity rather than the SSH key for the cluster.
Perhaps one could suggest users to shut down the deployer when it's not used to reduce the attack surface.
Currently, the terraform deployment step results in the
hpcadmin
SSH key being stored in cleartext in the volume of the deployer, which allows for lateral movement in the network.It would be preferable to use a local key management solution, such as password-protected (encrypted) SSH keys with an SSH agent and a timeout for
ssh-add
(e.g. 24h).The text was updated successfully, but these errors were encountered: