How Service Accounts Work
The purpose of Service Accounts
Service Accounts in Twingate are used to secure communications between remote machines. Because Service Accounts are used by machines to establish connections to Resources, Service Accounts cannot interact with Twingate Clients in the same way that humans would, and therefore those accounts differ from non-Service Accounts in several ways:
- Service Accounts cannot fulfill 2FA requirements
- Service Accounts cannot use standard credentials (such as a social login or identity provider account)
- Service Accounts leverage the Twingate Client in a non-interactive way called headless mode
Security of Service Accounts
Even though Service Accounts do not use standard credentials, they are still strongly secured by Service Keys which can be made to expire regularly and can be managed automatically via our APIs.
Let’s explore common use cases for Service Accounts.
Secure communication between SaaS and private Resources
Our customers often rely on both self-hosted components (on-premises or in a private cloud) and SaaS applications such as GitHub, CircleCI and others. In those cases, the SaaS applications require access to private infrastructure components (such as K8s clusters, virtual machines, etc.). Service Accounts combined with the Twingate Client (in headless mode) are used to securely connect your SaaS applications to your private Twingate Resources.
Take a look at our practical guides on this topic:
- How to connect CircleCI and Github Actions to Private Resources
- How to connect Github Codespaces to Private Resources
Secure communication between two private Resources across different sites
Apart from SaaS applications like GitHub and CircleCI, Service Accounts can also be used to secure connections across private remote systems hosted in different sites. The best approach for this use case is to deploy the Twingate Client in headless mode on the system which requires connectivity to private and remote Twingate Resources.
Secure communication between a pool of devices and private Resources
If the Twingate Client (in headless mode) cannot be deployed directly on the system which requires connectivity to remote and private Resources (for instance, if the system hosts an operating system that is incompatible with the Twingate Client), we recommend the following:
- Set up a separate virtual machine with a Twingate Client in headless mode. This virtual machine will act as a gateway for traffic coming from unsupported systems.
- Enable IP forwarding on the gateway virtual machine
- Set a route on a layer 3 switch or router to point all traffic through the virtual machine gateway
Setting up Ubuntu as a gateway
As a practical example, the above instructions can be implemented on an Ubuntu virtual machine in the following way:
- create a Service Account in your Twingate tenant
- install the Twingate Client in headless mode (set up to use the Service Account)
- enable IP forwarding by uncommenting
#net.ipv4.ip_forward=1in/etc/sysctl.conf - apply the changes by running
sudo sysctl -p - start the Twingate Client in headless mode
- set up a route on a layer 3 switch or router to point all tunneled resources through the Ubuntu gateway
Last updated 9 months ago