Allowlist non-sensitive data on Terraform state

[0x2b3bfa0]

To avoid future issues, we're migrating to a safer approach where we explicitly choose what to display instead of what to hide.

The cloudSshPrivateVisible option was introduced as a transition measure, but isn't necessary: users can always specify a custom key with --cloud-ssh-private

[DavidGOrtega]

@0x2b3bfa0 if we remove the functionality of showing the ssh we HAVE to remove the capability of creating the SSH automatically with all the friction that it generates. Makes no sense that we are able to create SSH keys and nt being able to give it back to them.
I think that giving them the capability of showing it at their own risk is acceptable

Let's do it. They can specify the SSH so it might be fine. The rationale of my original thought is because there are some users that might not know how to generate SSH keys (i found them), so I wanted to provide them it back

[0x2b3bfa0]

Let's do it. They can specify the SSH so it might be fine.

Awesome! In my opinion, specifying the SSH private key is, if not the best solution, at least a good short term compromise between printing keys to the logs and having users do everything manually.

The rationale of my original thought is because there are some users that might not know how to generate SSH keys (I found them), so I wanted to provide them it back.

If that's the case, let's document the process:

1. Generate² a new SSH RSA (PEM) private key:

   $ ssh-keygen -t rsa -m pem -b 4096 -f key.pem

2. Pass the --cloud-ssh-private to cml-runner including the contents¹ of newly genereated private key file:

   $ cml-runner --cloud ··· --cloud-ssh-private="$(cat key.pem)"

---

¹ Would be a bit more involved if we don't resort to the changes introduced with #602. Using perl or sed for this is not precisely an user-friendly solution.
² Hardcoding key bit lengths in documentation is not future-proof, but perhaps better than recommending the default 3072 bit length.

[0x2b3bfa0]

🔔 @casperdcl, should we add this to the wiki under the cml-runner reference section?

[DavidGOrtega]

I would say no. What you are doing with that is making users generate the "useless" keys by themselves so the inbuilt feature is not needed anymore

[0x2b3bfa0]

if we remove the functionality of showing the ssh we HAVE to remove the capability of creating the SSH automatically with all the friction that it generates. Makes no sense that we are able to create SSH keys and nt being able to give it back to them.

It does make sense as long as we keep using them internally for log retrieval in some platforms as per iterative/terraform-provider-iterative#70. Anyhow.

I think that giving them the capability of showing it at their own risk is acceptable.

I don't want to be one of these cryptographers that develop popular libraries¹ and explicitly forbid users from using certain functions, even if they know what they're doing.

Nevertheless, providing this functionality, for the reasons exposed in #598 (comment), could be equivalent to adding a yellow Tweet my Private Keys button in your favorite crypto wallet. 😉

[0x2b3bfa0]

👌🏼 As long as they get it right...

[casperdcl]

should we add this to the wiki

please do!

[0x2b3bfa0]

Done! It leaves room for improvement, but at least it won't get lost.

[DavidGOrtega]

I do not fully understand why we need that. Docs says:

Custom private RSA SSH key. If not provided an
                               automatically generated throwaway key will be
                               used

Additionally we are teaching them how to create a throwaway key? @casperdcl @0x2b3bfa0

[0x2b3bfa0]

If users take no action, the Terraform provider will automatically generate a throwaway key for internal use. This key won't be available to users and will only be used to retrieve machine logs and determine the runner status.

If users need to access the instance on their own, they will need to know how to provide their own key. As you can guess, we are also teaching them how to generate a new one because using their default key from .ssh/id_rsa:

1. Might not be an option, as it's usually in OpenSSH format, not in PEM format.
2. Would expose the user private key beyond what's acceptable in many scenarios.