Skip to content
Guides
/
/
Create a Service Account

Create a Service Account

In this tutorial, you'll create a dedicated service identity in Synqly for an automated provisioning workflow. The service will be able to create accounts and issue integration tokens using narrowly scoped permissions.

The scenario

Acme Corp is building Provisioning Service, an internal automation that runs whenever a new customer signs up. It must:

  1. Create a Synqly account for the customer and label it.
  2. Issue a short-lived Integration token once the customer selects a SIEM connector.

This service must operate independently from any human administrator credentials.

Prerequisites

  • A Synqly Organization token with administrator access, available from Settings → API Keys. This is used only for setup.
  • A tool to make HTTP requests, such as curl.

Step 1: Identify required permissions

Provisioning Service needs two capabilities:

  • Create and manage accounts
  • Issue integration tokens

These map to the account-manager and token-issuer permission sets.

While an administrator permission set could also work, it grants more access than this service requires. Narrow permissions reduce risk and make access easier to audit.

Step 2: Create two roles

Using your Organization token, create two roles scoped only to provisioning resources. Both roles are restricted to accounts labeled acme-provisioning in production.

curl -i -X POST \
  https://api.synqly.com/v1/roles \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "provisioning-service-accounts",
    "resources": {
      "accounts": {
        "labels": [
          "acme-provisioning"
        ],
        "environments": [
          "prod"
        ],
        "ids": [
          "52e9fc2e-e67f-4439-b85e-0c7e8070dfeb"
        ]
      }
    },
    "permission_set": "account-manager"
  }'
curl -i -X POST \
  https://api.synqly.com/v1/roles \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "provisioning-service-token-issuer",
    "resources": {
      "accounts": {
        "labels": [
          "acme-provisioning"
        ],
        "environments": [
          "prod"
        ],
        "ids": [
          "52e9fc2e-e67f-4439-b85e-0c7e8070dfeb"
        ]
      }
    },
    "permission_set": "token-issuer"
  }'

Both roles use the same resource restrictions. This ensures the service can only operate on accounts it is explicitly allowed to manage.

Step 3: Create the service identity

Create a service account (a Member) for Provisioning Service and bind both roles to it.

curl -i -X POST \
  https://api.synqly.com/v1/members \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "svc-provisioning@acme.io",
    "secret": "<strong-secret>",
    "role_binding": [
      "provisioning-service-accounts",
      "provisioning-service-token-issuer"
    ],
    "type": "service"
  }'

This identity now has the combined permissions of both roles, with the same resource restrictions.

The effective access is the union of both roles, but always constrained by the shared boundary.

Step 4: Choose how the service authenticates

Provisioning Service needs its own runtime credential. There are two supported approaches:

Authenticate as the service account to obtain a TokenPair.

This creates a named, auditable identity tied to svc-provisioning@acme.io. Access is revoked by disabling or deleting the member.

Use this approach when you want identity tracking and long-lived service ownership.

Both approaches result in the same effective permissions. The difference is lifecycle: one is identity-based, the other is time-bound.

Step 5: Create the customer account

Using its provisioning credentials, the service creates a new account:

curl -i -X POST \
  https://api.synqly.com/v1/accounts \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "customer-acme-123",
    "labels": [
      "acme-provisioning"
    ]
  }'

The label is critical. It ensures the account remains within the service's resource restriction and stays manageable by the same roles.

Step 6: Issue an integration token for the customer

Once the customer selects a SIEM integration, the service issues a short-lived Integration token.

curl -i -X POST \
  'https://api.synqly.com/v1/tokens/{accountId}/{integrationId}' \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  -H 'Content-Type: application/json' \
  -d '{
    "token_ttl": "10m"
  }'

This token is used only by the customer's application to configure the integration. It is separate from the provisioning service's own credentials and is scoped only to the Connector APIs — it does not grant access to the Management APIs.

The customer's application passes this token to the Connector API to perform provider operations:

curl -i -X GET \
  https://api.synqly.com/v1/siem/events \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>'

For more detail on integration token scope and lifecycle, see Integration Access Tokens.

What you built

You created a dedicated service identity with two narrowly scoped roles, both constrained by the same resource restriction. That identity operates only within the acme-provisioning production boundary.

The service can:

  • Create and manage accounts it owns
  • Issue integration tokens for those accounts

It cannot:

  • Access other accounts
  • Escalate permissions beyond its roles

This ensures that even if the service is compromised, the impact remains limited to a clearly defined boundary rather than the entire organization.

Previous page
Next page