Access Control for Staging Environments

A common pattern for product and web development is to separate staging and development environments from production. Twingate makes it easy to control who can access each environment without 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, -and-access-nodes#resourceResources 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:

# Staging environment
# AWS VPC, subnet, private DNS
#       # Staging web server # Local Twingate Connector

# Development environment
# AWS VPC, subnet, private DNS
#           # Development web server # Local Twingate Connector

# Production
# Public DNS, delivered via AWS CloudFront (CDN)

With Twingate deployed on each local subnet, Twingate users that have been given access to will be transparently routed to the development subnet and their request will resolve to the development server. This routing is invisible to the user and requires no configuration changes on their part.

Benefits of this approach

Compared to the traditional approach of asking users to connect to the necessary environment—for example, by disconnecting and reconnecting a VPN client to a new environment—Twingate offers significant advantages.

  • 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. Note: 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 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.

Did this page help you?