New Linux Client & Designing Twingate for Developers
Lior Rozner
•
Aug 19, 2020
We’re delighted to announce the release of our Twingate client app for Linux! With this release, Twingate now supports all major desktop and mobile operating systems, including Android, iOS, macOS, and Windows.
We’re particularly excited about this because of its relevance to the group of users who we had in mind when we started building Twingate: developers.
We wanted to share our thinking behind designing secure, remote access for developers. While companies have trended towards remote work for everyone - something accelerated by the COVID-19 pandemic - remote access is not new for engineering organizations. We focus on developers for several reasons:
They’re the group in an organization that often relies the most on remote access to perform their jobs.
As more developer workloads move to the cloud, developers are essentially always working remotely and often have complex access needs across multiple cloud platforms.
We are developers ourselves and would love never to have to wrangle with VPNs again!
No one loves their VPN, especially developers
When we were designing Twingate, we interviewed over fifty IT, security, and networking professionals to understand the existing pain with remote access. While everyone we spoke to viewed the remote access experience as broken, we consistently heard that the experience for developers was particularly painful. Unlike non-developers who usually interact primarily with public-facing SaaS applications, most of the resources that developers access are protected behind closed, private networks. And this is for good reason: these resources are some of the most sensitive assets in a company. Databases, servers, production networks, etc. all require a higher level of protection. However, the challenge is that the existing VPN + perimeter-based model for providing secure remote access to these resources is broken, as we covered in an earlier post.
For developers, the problems with remote access primarily manifest in these ways:
Poor end-user experience with slow connections and unreliable clients VPNs are primarily set up as “full tunnel,‚ which means that all the traffic from your device is routed through a central VPN gateway when your VPN is turned on. This is particularly problematic when your VPN forces high-bandwidth apps like video conferencing (e.g. Zoom, Google Meet) through a VPN tunnel to your central network, adding unnecessary latency and network congestion. Some VPN clients can be set up to “split tunnel‚ traffic but are overly complex to set up. Moreover, VPN clients are often unreliable, regularly disconnecting when you move WiFi networks, close your laptop lid, etc. It’s like suffering from death by a thousand cuts.
Complex to set up and maintain due to network restructuring requirements Setting up remote access is complex because it requires you to restructure your network to enable remote access: creating a DMZ, dedicated subnets, routing rules, firewall settings, etc. Many developers spend hours or days wrangling VPNs to work correctly, and parsing the set up instructions can be tedious, error-prone, and time-consuming. Furthermore, if anything changes on the network or if you need to add a new VPC or network segment, you have to do this all over again. For organizations with even a small team of developers, this becomes a large burden to carry.
Difficult to implement modern security practices given this complexity Because of all this friction, it’s extremely challenging to implement important security practices like proper network and resource segmentation, least-privileged user access permissions, and SSO/MFA policies for developer resources. Most development teams end up over-provisioning access so users have much broader access than they actually need, and have to manage multiple systems that hold credentials, keys, etc. This is particularly challenging for onboarding and offboarding users, and many companies end up spending inordinate amounts of time provisioning accounts and setting up devices for users.
Remote access that “just works‚
When we designed Twingate, we made it our mission to create a modern solution for remote access that “just works‚ for users, reduces management overhead for IT/DevOps, and significantly upgrades your security posture out of the box. One of our primary product goals was to design Twingate to be set up in 15 minutes or less, and we also designed a rich feature set to address the specific pain points for developers.
Twingate operates as a “remote access‚ overlay on your existing network that authorizes each connection request and routes it directly to the right destination. This means Twingate requires no changes to your network infrastructure, no changes to your apps and services, and no changes to your devices to get up and running. Just add our network connectors to any number of network segments (on-prem, cloud, multi-cloud, doesn’t matter!), define user access permissions by destination address, and install the Twingate client app to access. No complicated firewall rules, routing rule changes, or complex proxy settings.
Also, unlike other “mesh‚ private network products, we don’t require you to remap every destination resource to new IP addresses. Users connect to their resources using the existing destination addresses they’ve always used and Twingate does all the heavy lifting in the background to route traffic appropriately to the right destination.
We’ve invested in a number of features designed specifically to remove the friction for developer workflows:
Always-on smart routing that segregates traffic automatically Our client apps are designed to automatically route traffic to the right destination with minimum latency. Authorized connections bound for private resources are routed directly to the destination network, unauthorized access attempts never even leave the device, and public internet traffic exits over default routes of the device to minimize any performance hit for the user. Our clients are lightweight and have a minimal CPU and memory footprint, and we’ve spent years of R&D and field testing our client technology across virtually every type of network environment to ensure high performance.
Protocol agnostic so every service works out of the box With Twingate, every service works out of the box. RDP, SSH, and (of course) HTTPS all work without requiring any configuration changes to devices or destination services. No proxy settings, SAML configuration, or PAM module configuration required. Twingate intelligently forwards any authorized connections to the right destination, regardless of the application. Even private DNS names are resolved correctly without changes to local device DNS settings!
Deployment automation to integrate into existing CI/CD pipelines We know that modern development teams automate everything (or at least try to!), and Twingate is designed to seamlessly integrate with “infrastructure as code‚ processes. Twingate can be fully managed via our API that allows access policies to be applied as services and resources are spun up and down. Our network connectors are also fully containerized and can be integrated into Terraform templates and Helm charts.
Extend SSO & MFA checks to any arbitrary service Twingate delegates authentication to your existing Identity Provider, and provides an extra layer of authorization for every connection based on defined access policies. Because Twingate operates as a network authorization extension to your IDP policies, this allows you to set identity-based access policies that tie to your central IDP without requiring any modifications to the end resource. This is particularly helpful for resources like databases, servers, and clusters that don’t play nicely with your IDP or in some cases don’t provide an interface for user authentication at all. Twingate can enable your IDP to fully function as a central service that can be used to easily on/offboard developers and reduce the overhead of managing multiple authentication systems for access to your developer resources.
“Zero trust‚ security without the hassle Finally, Twingate provides the easiest path to achieving a “zero trust‚ security posture. Least privilege access policies can be narrowly defined by resource to roles and groups, users never “join the network‚ which prevents lateral movement by potential attackers, and the lack of public VPN gateways eliminates a major entry point for attacks. Detailed analytics also provide newfound visibility into access patterns to identify potential security issues. Twingate has been designed to restore the balance between security and usability, and provide a strictly improved security posture compared to traditional VPN-based approaches to remote access.
Get started for free today
As developers ourselves, we know the pain of securing remote access. We were motivated to solve this problem because every solution on the market presented a tradeoff between security and usability. We believe this was a false choice because security practices and products only work if they are embraced by users!
If you’re a developer considering deploying a VPN or are already using one, we’d love for you to try Twingate and see the experience yourself. Sign up for free here.
We also invite you to read more about our technology at our documentation site.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
New Linux Client & Designing Twingate for Developers
Lior Rozner
•
Aug 19, 2020
We’re delighted to announce the release of our Twingate client app for Linux! With this release, Twingate now supports all major desktop and mobile operating systems, including Android, iOS, macOS, and Windows.
We’re particularly excited about this because of its relevance to the group of users who we had in mind when we started building Twingate: developers.
We wanted to share our thinking behind designing secure, remote access for developers. While companies have trended towards remote work for everyone - something accelerated by the COVID-19 pandemic - remote access is not new for engineering organizations. We focus on developers for several reasons:
They’re the group in an organization that often relies the most on remote access to perform their jobs.
As more developer workloads move to the cloud, developers are essentially always working remotely and often have complex access needs across multiple cloud platforms.
We are developers ourselves and would love never to have to wrangle with VPNs again!
No one loves their VPN, especially developers
When we were designing Twingate, we interviewed over fifty IT, security, and networking professionals to understand the existing pain with remote access. While everyone we spoke to viewed the remote access experience as broken, we consistently heard that the experience for developers was particularly painful. Unlike non-developers who usually interact primarily with public-facing SaaS applications, most of the resources that developers access are protected behind closed, private networks. And this is for good reason: these resources are some of the most sensitive assets in a company. Databases, servers, production networks, etc. all require a higher level of protection. However, the challenge is that the existing VPN + perimeter-based model for providing secure remote access to these resources is broken, as we covered in an earlier post.
For developers, the problems with remote access primarily manifest in these ways:
Poor end-user experience with slow connections and unreliable clients VPNs are primarily set up as “full tunnel,‚ which means that all the traffic from your device is routed through a central VPN gateway when your VPN is turned on. This is particularly problematic when your VPN forces high-bandwidth apps like video conferencing (e.g. Zoom, Google Meet) through a VPN tunnel to your central network, adding unnecessary latency and network congestion. Some VPN clients can be set up to “split tunnel‚ traffic but are overly complex to set up. Moreover, VPN clients are often unreliable, regularly disconnecting when you move WiFi networks, close your laptop lid, etc. It’s like suffering from death by a thousand cuts.
Complex to set up and maintain due to network restructuring requirements Setting up remote access is complex because it requires you to restructure your network to enable remote access: creating a DMZ, dedicated subnets, routing rules, firewall settings, etc. Many developers spend hours or days wrangling VPNs to work correctly, and parsing the set up instructions can be tedious, error-prone, and time-consuming. Furthermore, if anything changes on the network or if you need to add a new VPC or network segment, you have to do this all over again. For organizations with even a small team of developers, this becomes a large burden to carry.
Difficult to implement modern security practices given this complexity Because of all this friction, it’s extremely challenging to implement important security practices like proper network and resource segmentation, least-privileged user access permissions, and SSO/MFA policies for developer resources. Most development teams end up over-provisioning access so users have much broader access than they actually need, and have to manage multiple systems that hold credentials, keys, etc. This is particularly challenging for onboarding and offboarding users, and many companies end up spending inordinate amounts of time provisioning accounts and setting up devices for users.
Remote access that “just works‚
When we designed Twingate, we made it our mission to create a modern solution for remote access that “just works‚ for users, reduces management overhead for IT/DevOps, and significantly upgrades your security posture out of the box. One of our primary product goals was to design Twingate to be set up in 15 minutes or less, and we also designed a rich feature set to address the specific pain points for developers.
Twingate operates as a “remote access‚ overlay on your existing network that authorizes each connection request and routes it directly to the right destination. This means Twingate requires no changes to your network infrastructure, no changes to your apps and services, and no changes to your devices to get up and running. Just add our network connectors to any number of network segments (on-prem, cloud, multi-cloud, doesn’t matter!), define user access permissions by destination address, and install the Twingate client app to access. No complicated firewall rules, routing rule changes, or complex proxy settings.
Also, unlike other “mesh‚ private network products, we don’t require you to remap every destination resource to new IP addresses. Users connect to their resources using the existing destination addresses they’ve always used and Twingate does all the heavy lifting in the background to route traffic appropriately to the right destination.
We’ve invested in a number of features designed specifically to remove the friction for developer workflows:
Always-on smart routing that segregates traffic automatically Our client apps are designed to automatically route traffic to the right destination with minimum latency. Authorized connections bound for private resources are routed directly to the destination network, unauthorized access attempts never even leave the device, and public internet traffic exits over default routes of the device to minimize any performance hit for the user. Our clients are lightweight and have a minimal CPU and memory footprint, and we’ve spent years of R&D and field testing our client technology across virtually every type of network environment to ensure high performance.
Protocol agnostic so every service works out of the box With Twingate, every service works out of the box. RDP, SSH, and (of course) HTTPS all work without requiring any configuration changes to devices or destination services. No proxy settings, SAML configuration, or PAM module configuration required. Twingate intelligently forwards any authorized connections to the right destination, regardless of the application. Even private DNS names are resolved correctly without changes to local device DNS settings!
Deployment automation to integrate into existing CI/CD pipelines We know that modern development teams automate everything (or at least try to!), and Twingate is designed to seamlessly integrate with “infrastructure as code‚ processes. Twingate can be fully managed via our API that allows access policies to be applied as services and resources are spun up and down. Our network connectors are also fully containerized and can be integrated into Terraform templates and Helm charts.
Extend SSO & MFA checks to any arbitrary service Twingate delegates authentication to your existing Identity Provider, and provides an extra layer of authorization for every connection based on defined access policies. Because Twingate operates as a network authorization extension to your IDP policies, this allows you to set identity-based access policies that tie to your central IDP without requiring any modifications to the end resource. This is particularly helpful for resources like databases, servers, and clusters that don’t play nicely with your IDP or in some cases don’t provide an interface for user authentication at all. Twingate can enable your IDP to fully function as a central service that can be used to easily on/offboard developers and reduce the overhead of managing multiple authentication systems for access to your developer resources.
“Zero trust‚ security without the hassle Finally, Twingate provides the easiest path to achieving a “zero trust‚ security posture. Least privilege access policies can be narrowly defined by resource to roles and groups, users never “join the network‚ which prevents lateral movement by potential attackers, and the lack of public VPN gateways eliminates a major entry point for attacks. Detailed analytics also provide newfound visibility into access patterns to identify potential security issues. Twingate has been designed to restore the balance between security and usability, and provide a strictly improved security posture compared to traditional VPN-based approaches to remote access.
Get started for free today
As developers ourselves, we know the pain of securing remote access. We were motivated to solve this problem because every solution on the market presented a tradeoff between security and usability. We believe this was a false choice because security practices and products only work if they are embraced by users!
If you’re a developer considering deploying a VPN or are already using one, we’d love for you to try Twingate and see the experience yourself. Sign up for free here.
We also invite you to read more about our technology at our documentation site.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
New Linux Client & Designing Twingate for Developers
Lior Rozner
•
Aug 19, 2020
We’re delighted to announce the release of our Twingate client app for Linux! With this release, Twingate now supports all major desktop and mobile operating systems, including Android, iOS, macOS, and Windows.
We’re particularly excited about this because of its relevance to the group of users who we had in mind when we started building Twingate: developers.
We wanted to share our thinking behind designing secure, remote access for developers. While companies have trended towards remote work for everyone - something accelerated by the COVID-19 pandemic - remote access is not new for engineering organizations. We focus on developers for several reasons:
They’re the group in an organization that often relies the most on remote access to perform their jobs.
As more developer workloads move to the cloud, developers are essentially always working remotely and often have complex access needs across multiple cloud platforms.
We are developers ourselves and would love never to have to wrangle with VPNs again!
No one loves their VPN, especially developers
When we were designing Twingate, we interviewed over fifty IT, security, and networking professionals to understand the existing pain with remote access. While everyone we spoke to viewed the remote access experience as broken, we consistently heard that the experience for developers was particularly painful. Unlike non-developers who usually interact primarily with public-facing SaaS applications, most of the resources that developers access are protected behind closed, private networks. And this is for good reason: these resources are some of the most sensitive assets in a company. Databases, servers, production networks, etc. all require a higher level of protection. However, the challenge is that the existing VPN + perimeter-based model for providing secure remote access to these resources is broken, as we covered in an earlier post.
For developers, the problems with remote access primarily manifest in these ways:
Poor end-user experience with slow connections and unreliable clients VPNs are primarily set up as “full tunnel,‚ which means that all the traffic from your device is routed through a central VPN gateway when your VPN is turned on. This is particularly problematic when your VPN forces high-bandwidth apps like video conferencing (e.g. Zoom, Google Meet) through a VPN tunnel to your central network, adding unnecessary latency and network congestion. Some VPN clients can be set up to “split tunnel‚ traffic but are overly complex to set up. Moreover, VPN clients are often unreliable, regularly disconnecting when you move WiFi networks, close your laptop lid, etc. It’s like suffering from death by a thousand cuts.
Complex to set up and maintain due to network restructuring requirements Setting up remote access is complex because it requires you to restructure your network to enable remote access: creating a DMZ, dedicated subnets, routing rules, firewall settings, etc. Many developers spend hours or days wrangling VPNs to work correctly, and parsing the set up instructions can be tedious, error-prone, and time-consuming. Furthermore, if anything changes on the network or if you need to add a new VPC or network segment, you have to do this all over again. For organizations with even a small team of developers, this becomes a large burden to carry.
Difficult to implement modern security practices given this complexity Because of all this friction, it’s extremely challenging to implement important security practices like proper network and resource segmentation, least-privileged user access permissions, and SSO/MFA policies for developer resources. Most development teams end up over-provisioning access so users have much broader access than they actually need, and have to manage multiple systems that hold credentials, keys, etc. This is particularly challenging for onboarding and offboarding users, and many companies end up spending inordinate amounts of time provisioning accounts and setting up devices for users.
Remote access that “just works‚
When we designed Twingate, we made it our mission to create a modern solution for remote access that “just works‚ for users, reduces management overhead for IT/DevOps, and significantly upgrades your security posture out of the box. One of our primary product goals was to design Twingate to be set up in 15 minutes or less, and we also designed a rich feature set to address the specific pain points for developers.
Twingate operates as a “remote access‚ overlay on your existing network that authorizes each connection request and routes it directly to the right destination. This means Twingate requires no changes to your network infrastructure, no changes to your apps and services, and no changes to your devices to get up and running. Just add our network connectors to any number of network segments (on-prem, cloud, multi-cloud, doesn’t matter!), define user access permissions by destination address, and install the Twingate client app to access. No complicated firewall rules, routing rule changes, or complex proxy settings.
Also, unlike other “mesh‚ private network products, we don’t require you to remap every destination resource to new IP addresses. Users connect to their resources using the existing destination addresses they’ve always used and Twingate does all the heavy lifting in the background to route traffic appropriately to the right destination.
We’ve invested in a number of features designed specifically to remove the friction for developer workflows:
Always-on smart routing that segregates traffic automatically Our client apps are designed to automatically route traffic to the right destination with minimum latency. Authorized connections bound for private resources are routed directly to the destination network, unauthorized access attempts never even leave the device, and public internet traffic exits over default routes of the device to minimize any performance hit for the user. Our clients are lightweight and have a minimal CPU and memory footprint, and we’ve spent years of R&D and field testing our client technology across virtually every type of network environment to ensure high performance.
Protocol agnostic so every service works out of the box With Twingate, every service works out of the box. RDP, SSH, and (of course) HTTPS all work without requiring any configuration changes to devices or destination services. No proxy settings, SAML configuration, or PAM module configuration required. Twingate intelligently forwards any authorized connections to the right destination, regardless of the application. Even private DNS names are resolved correctly without changes to local device DNS settings!
Deployment automation to integrate into existing CI/CD pipelines We know that modern development teams automate everything (or at least try to!), and Twingate is designed to seamlessly integrate with “infrastructure as code‚ processes. Twingate can be fully managed via our API that allows access policies to be applied as services and resources are spun up and down. Our network connectors are also fully containerized and can be integrated into Terraform templates and Helm charts.
Extend SSO & MFA checks to any arbitrary service Twingate delegates authentication to your existing Identity Provider, and provides an extra layer of authorization for every connection based on defined access policies. Because Twingate operates as a network authorization extension to your IDP policies, this allows you to set identity-based access policies that tie to your central IDP without requiring any modifications to the end resource. This is particularly helpful for resources like databases, servers, and clusters that don’t play nicely with your IDP or in some cases don’t provide an interface for user authentication at all. Twingate can enable your IDP to fully function as a central service that can be used to easily on/offboard developers and reduce the overhead of managing multiple authentication systems for access to your developer resources.
“Zero trust‚ security without the hassle Finally, Twingate provides the easiest path to achieving a “zero trust‚ security posture. Least privilege access policies can be narrowly defined by resource to roles and groups, users never “join the network‚ which prevents lateral movement by potential attackers, and the lack of public VPN gateways eliminates a major entry point for attacks. Detailed analytics also provide newfound visibility into access patterns to identify potential security issues. Twingate has been designed to restore the balance between security and usability, and provide a strictly improved security posture compared to traditional VPN-based approaches to remote access.
Get started for free today
As developers ourselves, we know the pain of securing remote access. We were motivated to solve this problem because every solution on the market presented a tradeoff between security and usability. We believe this was a false choice because security practices and products only work if they are embraced by users!
If you’re a developer considering deploying a VPN or are already using one, we’d love for you to try Twingate and see the experience yourself. Sign up for free here.
We also invite you to read more about our technology at our documentation site.
Solutions
Solutions
The VPN replacement your workforce will love.
Solutions