Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support internal-facing gateways on AWS #1171

Closed
r4victor opened this issue Apr 25, 2024 · 3 comments · Fixed by #1224
Closed

Support internal-facing gateways on AWS #1171

r4victor opened this issue Apr 25, 2024 · 3 comments · Fixed by #1224
Assignees
Labels

Comments

@r4victor
Copy link
Collaborator

r4victor commented Apr 25, 2024

Currently, dstack AWS gateways are instances with public IP addresses. Users may want to create an internal-facing gateway so that the gateway is only accessible via internal IP inside the VPC. Users would still assign a domain to the gateway that is publicly resolved, but it's resolved to internal IP. This is similar to the AWS internal load balancer.

The limitations of internal-facing gateways:

  • The dstack server must be deployed in the same VPC as gateways so that they can communicate.
  • The SSL certificates can't be renewed automatically via certbot since ACME providers cannot access the gateway. We cloud allow disabling https or ask users for SSL certificates that they can acquire via DNS, for example.

Next step would be to support internal-facing gateways in all providers that allow for that.

@r4victor
Copy link
Collaborator Author

I suggest the following interface to create internal-facing gateways:

  1. Users can specify the new gateway parameter visibility. By default, it's visibility: public. To create an internal-facing gateway, users specify visibility: private.
  2. Optionally, users can specify subnet_id for deploying the gateway in a specific subnet. The VPC is chosen according to the backend configuration.

@r4victor
Copy link
Collaborator Author

To issue SSL certificates for internal-facing gateways, we can use ACME DNS-01 challenge instead of HTTP-01 challenge used currently for public gateways. It will require creds/permissions to automatically manage the DNS records for the users' domains. The DNS-01 challenge is automated for many DNS providers: https://github.com/dehydrated-io/dehydrated/wiki

@r4victor r4victor self-assigned this May 13, 2024
@r4victor
Copy link
Collaborator Author

As the first option to enable https on gateways without public IPs, we decided to allow users to specify their AWS Certificate Manager certificates when creating gateways. This approach should be familiar to AWS users and would not require permissions to manage DNS zones.

To support this, we'll provision such private gateways behind a load balancer with a certificate attached to the LB.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant