[New Resource]: AWS SSM tunnel

[dm3ch]

Description

In some cases you may need to connect terraform provider to for example database that are unavailable from the machine running terraform. AWS have aws ssm port-forwarding as a default proposed method to access resources that are only available via private network.

As maintainer wrote it of comunnity-maintained PostgreSQL provider it would be not effective to make postgres provider to work with cloud specific tunneling solutions for each cloud - cyrilgdn/terraform-provider-postgresql#81 (comment). Cause this functionality can be reused between different providers.

In terraform issue hashicorp/terraform#8367 (comment) itself it was proposed to create separate ephemeral resource for such tunnel. So I propose to consider adding such ephemeral resource to handle aws ssm tunnel creation and later use it in other providers configuration

Requested Resource(s) and/or Data Source(s)

• aws_ssn_tunnel - like it was proposed at Proposal: port forwarding via SSH tunnel terraform#8367 (comment)

Potential Terraform Configuration

# INVALID: This is a hypothetical new concept of "ephemeral resources"
# that we're currently considering as part of a solution to this issue.
ephemeral "aws_ssm_tunnel" "mysql_server" {
  instance_id = aws_instance.example.id
  remote_port = 3306
}

provider "mysql" {
  # The local_endpoint attribute would be something like 127.0.0.1:33453,
  # where 33453 is a randomly-selected TCP port number that serves
  # as the local end of the tunnel.
  endpoint = ephemeral.aws_ssm_tunnel.mysql_server.local_endpoint

  # ...
}

### References

_No response_

### Would you like to implement a fix?

None

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[sdemjanenko]

This would be amazing. I wrote a custom provider to do exactly this, but there are some edge cases where a keepalive resource is needed to keep the tunnel alive until resources are modified. Also it doesn't work well when removing resources. See: https://registry.terraform.io/providers/ComplyCo/aws-ssm-tunnels/latest

@dm3ch as a note, I use this to manage resources in RDS and EKS in a private VPC.

[dm3ch]

@sdemjanenko Thank you I would take a look.

To be honest I was going to write provider myself if AWS provider wouldn't have such feature, but I'm happy that it's not needed, cause someone already done this

[dm3ch]

@sdemjanenko After a quick look I see that you are using standard resources and not ephemeral ones, isn't it?

As far as I understand the conversion of resources to ephemeral (with TF 1.10) would allow to bind to lifecycle hooks that would allow it to use during apply, plan, destroy without any issues. If I right understood initial discussion in hashicorp/terraform#8367

[sdemjanenko]

@dm3ch yes, i am planning on switching to ephemeral once 1.10 hits GA. I am not certain that the lifecycle will be properly tracked (allowing removal of the keepalive resources). That is something I need to test.

From my cursory understanding of ephemeral resources, I believe it will only allow me to get rid of the UUID trick I do to force the tunnel to get set up in the Apply step (https://github.com/ComplyCo/terraform-provider-aws-ssm-tunnels/blob/main/internal/provider/remote_tunnel_resource.go#L192). But this is something I plan on testing to see how much it can simplify and improve the developer experience of the provider.