Services offer a way to provide programmatic, centrally-controlled, and consistent access controls for automated processes such as CI/CD pipelines and custom applications. Any Resource that is defined in Twingate can be assigned to a Service, User, or both. This allows you to create consistent zero trust access controls across your infrastructure.
More specific details are described below, but the following summarizes the capabilities of Services in Twingate:
- Any Resource in Twingate may be assigned directly to a Service.
- Security Policies do not apply to Services, and instead, access is granted by a valid Service Key.
- Either the Linux or Windows clients may be run in "headless" mode to automate connection and access to Resources assigned to a Service.
Connector upgrade to v1.0.30 or later is required
Services are only supported in v1.0.30 of the Connector or later. If you cannot add a Resource to a Service, you will need to update the Connector associated with that Resource first.
There are three components to a Service:
- The Service. This is the container object that is used to configure the Service. You can find Services under the "Team" tab in the Admin console.
- One or more Service Keys. Service Keys are used to authorize access to all Resources assigned to a Service. Any Service Key that has not been revoked or has not expired can be used to access Resources assigned to a Service. Service Key expiration can be configured at creation time and expire after 365 days by default.
- One or more Resources assign to a Service. Any Resource defined in Twingate can be assigned to a Service.
- Navigate to Team > Services, and select "Create Service Account"
- Select "Generate Key" to create a new Service Key
- Save the new Service Key. This is the only time that the Service Key can be viewed and copied.
- Select "Add Resource" to assign Resource(s) to the Service. Any Service Key authorizes access to all Resources assigned to the Service.
You are now ready to access the Service's Resources programmatically using either our Windows or Linux clients in headless mode. See the instructions below for the client configuration steps.
Valid Service Key states are summarized in the table below.
This is the default state for a new Service Key. Service Keys are only valid and usable when active.
Service Key expiry can only be set at creation time; unlimited expiration is allowed.
The Service Key's name may also be edited while active.
Service Keys must be revoked before they are deleted.
Once revoked, keys cannot be made active again.
Service Keys expire automatically unless created with an unlimited expiration.
Service Keys that are deleted are permanently deleted and cannot be recovered.
Minimum supported client version
In order to use a Service Key to access a Service's Resources, either the Windows or Linux clients may be used in headless mode. Instructions for both clients are linked below.
We have included several example CI/CD configurations using the Linux client in headless mode that can serve as an example for similar use cases and configurations.
Updated 4 months ago