Best Practices for Securing Access to Non-production Environments
Logically separating all environments (development, staging, production, etc.) is a common pattern for product and web development but it often requires using different access points or clients for end users. Twingate makes this easier to control without reconfiguring the network or exposing anything about these environments publicly.
Core Principles
When users are connected to Twingate, how private traffic is routed is determined based on the destination host connection request. This decision is made before DNS resolution, which allows routing of traffic to different destinations based entirely on the FQDN in the user’s request.
When administering Twingate, Resources are coupled to Remote networks, which correspond to the target private network. Therefore, it is the address that determines what target network the user’s request will be routed to, and subsequently where DNS resolution of the destination host will happen. This allows the complexity of configuring separate environments to be hidden from the end user with the FQDN serving as sufficient abstraction.
Example Configuration for Development, Staging and Production
For example, consider a simple scheme to separate development and staging web environments:
Developers are given access to the Twingate Resource dev.beamreachinc.com: The routing to this Resource is decided by Twingate before DNS resolution: this means the developers are transparently routed to the development subnet and then their request gets resolved to the 10.0.2.77 by the local DNS on that subnet.
This routing is invisible to the user and requires no configuration changes on their part.
Don't have a local DNS setup for your subnets?
Check out our handy guide: Private DNS Best Practices
Benefits of this approach
Main Benenfit
This approach eliminates the typical requirement of asking users to actively connect / disconnect between multiple environments.
Naming is sufficient for the correct routing and authorization:
This greatly simplifies the user experience without introducing the additional complexity of needing special user authentication or updating access whitelist rules when using public DNS names.
If one of your environments is hosted publicly, but managing an access whitelist is your primary concern, see Whitelisting Traffic to Public Services for how Twingate can help.
Access can be given to internal and external users without providing access to the entire environment:
It’s often beneficial to provide access to individuals or groups that do not need access to the entire staging or development environment.
Externally, this could include contractors and vendors that your business works with. Internally, this might include product management, marketing, or the executive team.
These groups would be able to review changes in staging, say, by providing narrow access to the staging.beamreachinc.com staging server and nothing else.
Staging and development environments are invisible to the public internet:
Because private DNS is used, your environments are completely hidden from the public internet and only exposed to the users you authorize in Twingate.
This eliminates the risk of any resources being exposed unintentionally.
Users no longer need to know what backend network they are connecting to:
A common pattern with legacy VPN solutions is the need for the user to decide which network or environment they are connecting to.
Because Twingate handles this routing transparently based on the destination FQDN, users no longer need to consciously switch environments.
Try it for free
With Twingate Starter, you can easily create a private staging environment that is completely inaccessible from the public internet but still shareable with collaborators or clients — all without setting up a VPN, port forwarding, static IP addresses, or configuring DDNS.
The entire process takes only 3-4 minutes. Check out the tutorials below, which walk through all the steps of the setup process:
Please join us in our community subreddit to share and discuss your experience and any other use cases you’ve discovered.
Last updated 8 months ago