Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Twingate – A modern solution for remote access

twingate.com

Post reply on HN
Print view View original

11–20 of 52 posts

Re: Show HN: Twingate – A modern solution for remote access

#11

Post by hashamali »

alexmensch wrote: post #5
hashamali wrote: post #3

Very cool! How does this compare with Tailscale which utilizes Wireguard under the hood?

Thanks! One of the things that we've really focused on is making Twingate super, super easy to deploy. From all of our customers conversations we've found that despite acknowledging that a better approach to remote access is possible , most people are really turned off by how hard it seems to be to implement a "zero trust" type solution. Our product goal is a 15-minute deployment, and our initial customers have been…

Love this mission statement. I hope to never wrestle with VPN ever again. Good luck!

Re: Show HN: Twingate – A modern solution for remote access

#12

Post by alexmensch »

23david wrote: post #9

I've found that it's a good way to restrict access to testing/staging/dev environments. way easier to set up and manage than a vpn imo.

Totally! We've seen some nightmare configurations around separating dev/staging/prod environments involving scripts to change /etc/hosts back and forth and some funky VPN configurations.

This is such a common use case that we wrote up a brief description of how to approach this: https://docs.twingate.com/docs/access-control-for-staging-en...

Re: Show HN: Twingate – A modern solution for remote access

#15

Post by joshma »

We currently use a mildly exotic "temporary bastion" approach, where upon request / approval a dev can get a container launched. The container is launched on ECS running an ssh server, pinned to the dev's individual public key, and that container has the appropriate security groups / IAM roles to access various production resources.

Right now, a dev will 1) VPN to get shallow network access and 2) SSH over VPN to get deeper network access through the bastion container. Something like a database is security group'd off so that you need to be on the bastion container to access.

My question - would Twingate be able to support an ephemeral use case like this? I'm thinking ideally it can be launched as a sidecar container, and a dev could SSH through the twingate container. A lot of solutions I see don't seem to handle ephemeral situations super well, so I was curious.

Re: Show HN: Twingate – A modern solution for remote access

#18

Post by alexmensch »

e12e wrote: post #13

Does this in practice restrict to connect workstations/humans with services - or is there support for allowing services to talk to services too?

Currently, yes, we’re focused on connecting users with services, but there’s nothing inherent to the underlying technology that prevents us handling service to service communication in the future. This is a common request, and along with a public API that we plan to release in the future, we think we’ll have a very flexible solution for your use case down the line.

Re: Show HN: Twingate – A modern solution for remote access

#19

Post by alexmensch »

joshma wrote: post #15

We currently use a mildly exotic "temporary bastion" approach, where upon request / approval a dev can get a container launched. The container is launched on ECS running an ssh server, pinned to the dev's individual public key, and that container has the appropriate security groups / IAM roles to access various production resources. Right now, a dev will 1) VPN to get shallow network access and 2) SSH over VPN to get…

Hey, great question, and your setup seems very secure, but I’m sure it would be nice to reduce some of the overhead. The right way to support your ephemeral bastion use case with Twingate will ultimately be to use a public API that we plan to launch later this year. That will allow you programmatically deploy connectors as needed.

However, I’d also question whether you even need your ephemeral bastions anymore with Twingate. A big part of the value is that you can do away with any public entry points (even if they are secured as well as you’ve described) and very tightly control who can access hosts on your deeper network. Do your bastions do more than provide access points? For example, session auditing is pretty common.

Post reply on HN