hashicorp/terraform-provider-tls

Add support for ED25519 key algorithm

detro opened this issue · 9 comments

detro commented

Background

Support for the ED25519 key algorithm has been a community-requested feature for this provider for a while. The first issue we could track down was filed in May 2018 (#26). Since then, multiple contributors attempted to bridge this gap (#32 in Nov 2018, #59 in Oct 2019, #85 in Oct 2020).

We want to take this opportunity to thank all the contributors (@jbboehr, @kaidence, @invidian, @nikolay) for the PR they submitted, and also to apologize for the long delay in getting this set of functionalities added to this provider. HashiCorp has a policy to prioritize stability and bug-fixes over any new feature for our “utility providers”; but given the demand for this feature, we decided to look into this and see how we could fit ED25519 inside the feature set.

Proposal

To serve the community at our best, we want to provide a well-rounded implementation that adds support for ED25519. Specifically, we want it to match the same functionality coverage as per the currently-supported RSA and ECDSA.

The implementation will include changes to the following entities, so that they accept ED25519 as input in their algorithm / key_algorithm configuration fields:

Resources:

  • tls_private_key (#151)
    • Additional field: private_key_openssh
  • tls_cert_request (#173)
  • tls_locally_signed_cert (#173)
  • tls_self_signed_cert (#173)

Data sources:

  • tls_public_key (#160)

As work proceeds, PRs will be linked back to this issue for full context.

References

Addresses: #26
Supersedes: #32
Supersedes: #59
Supersedes: #85

tazjin commented

On prioritisation, note that this is starting to become a serious problem with the ongoing deprecations of RSA keys.

For example, right now a complete deployment flow of NixOS machines on AWS does not work as RSA keys being disabled by default in SSH servers have led to a situation of subtle incompatibilites:

  1. The SSH server will refuse connections with ssh-rsa keys by default, unless re-enabled in the configuration.
  2. Terraform can only generate RSA and ECDSA keys.
  3. AWS only supports RSA and ed25519 keys.
  4. In order to update the config for 1. after bootstrapping a machine, a working SSH key is needed.

This means current workarounds are that custom AMIs with RSA enabled need to be created, or keys need to be imported by other means than generation inside of Terraform. These kinds of problems will likely only increase in number from here on.

detro commented

@tazjin thank you - yes, no worries, this is happening :)

  • ❤️5
nikolay commented

Thank you, @detro. We hope it's happening soon as we now generate those outside of Terraform.

detro commented

👍 @nikolay - I'm still finding my pace as the newest member of the HashiCorp team that maintain these, but yours and other PRs definitely helped to get this moving faster.

  • 👍4
  • 🎉1
  • ❤️1
jseiser commented

It would be great if we could please get a release with the tls_private_key enabled.

tls_private_key

We are getting hardened RHEL 8 images from the security team, and we build custom AMI's with packer. Each ENV we create has a custom SSH key on the bastion host that is generated via terraform. As of this moment, terraform can no longer create working keys ( packer/golang ssh implementation breaks), so we have to either disable fips ( cant ) or have packer spin up public instances with temp keys.

If we could just create the proper keys in terraform this entire problem goes away.

Thank you.

detro commented

Hello @jseiser - thanks for your comment.

We are working full blast on this issue, and we are aware of the demand for ED25519.
As you can see in the description above, the objective can't just be to cover 1 resource: the provider, to preserve a high level of quality, needs to maintain a consistency and a "roundness" of it.

Example, the *_cert resources don't support ED25519 right now: that is part of this work.

As HashiCorp we see it as our mission to provide a high quality provider, and that means covering all the bases.

I hope this clarifies things and our approach to major feature requests like ED25519 support.

jseiser commented

@detro I appreciate the response, and ill honestly leave it alone after this.

the objective can't just be to cover 1 resource

I mean, it could.

As HashiCorp we see it as our mission to provide a high quality provider, and that means covering all the bases.

The current provider is deprecated/broken in certain situations. There is a fix in the code base for parts of it, that would increase the quality of the provider. So instead of getting some fixes, we get nothing fixed, for the promise of future fixes.

Again, I appreciate the effort and the response. I disagree with the process, but its your process and Ill leave it at that.

Thank you.

  • 👍4
detro commented

This feature is now fully implemented and we are gearing up for releasing v3.2.0.

The full feature set can be seen in #176 where we are refining the changelog.

  • 🎉7
github-actions commented

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.