You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We propose enhancing our current setup, which allows for the creation of a central master bastion using Warpgate, alongside 10 subordinate slave bastions, each corresponding to one of the 10 private subnets. This configuration enables:
The assignment of SSH targets for every VM in subnet A to slave bastion A, and similarly for subnet B to slave bastion B.
Subsequently, it becomes necessary to aggregate all targets from every VM across all subnets onto the master bastion, facilitating direct access to all private VMs through the master bastion.
However, this setup becomes considerably more complex with scaling, such as in scenarios involving 50 subnets with 200 VMs each. While a slave bastion can manage 200 targets, the master bastion would be overwhelmed with 10,000 targets. Managing such a volume is cumbersome, and the Warpgate web interface struggles to display an extensive list of 10,000 targets efficiently.
To address this, we suggest the introduction of a "generic target" feature for the master bastion. This feature would simplify configurations by allowing a single generic target entry to represent multiple specific targets. For example:
Name: 192.0.0.*
Target Host: 10.0.0.1
Username: myuser for the forwarding IP 192.168.0.2
With this feature, any connection attempt matching the 192.0.0.* pattern would be automatically forwarded to 10.0.0.1, eliminating the need to individually specify targets for 192.0.0.1 through 192.0.0.255 on the master bastion. This would greatly streamline management and enhance the usability of the Warpgate web interface for large-scale environments.
The text was updated successfully, but these errors were encountered:
Feature Request:
We propose enhancing our current setup, which allows for the creation of a central master bastion using Warpgate, alongside 10 subordinate slave bastions, each corresponding to one of the 10 private subnets. This configuration enables:
The assignment of SSH targets for every VM in subnet A to slave bastion A, and similarly for subnet B to slave bastion B.
Subsequently, it becomes necessary to aggregate all targets from every VM across all subnets onto the master bastion, facilitating direct access to all private VMs through the master bastion.
However, this setup becomes considerably more complex with scaling, such as in scenarios involving 50 subnets with 200 VMs each. While a slave bastion can manage 200 targets, the master bastion would be overwhelmed with 10,000 targets. Managing such a volume is cumbersome, and the Warpgate web interface struggles to display an extensive list of 10,000 targets efficiently.
To address this, we suggest the introduction of a "generic target" feature for the master bastion. This feature would simplify configurations by allowing a single generic target entry to represent multiple specific targets. For example:
Name: 192.0.0.*
Target Host: 10.0.0.1
Username: myuser for the forwarding IP 192.168.0.2
With this feature, any connection attempt matching the 192.0.0.* pattern would be automatically forwarded to 10.0.0.1, eliminating the need to individually specify targets for 192.0.0.1 through 192.0.0.255 on the master bastion. This would greatly streamline management and enhance the usability of the Warpgate web interface for large-scale environments.
The text was updated successfully, but these errors were encountered: