When a script, a continuous integration (CI) job, or an external service needs to act in Tines 3B, it shouldn't borrow a person's login. A service account is a non-human identity built for exactly this. Each one holds its own permissions and its own credentials, so your automation can act on its own, and you can see and control what it's allowed to do. This guide covers creating a service account, giving it access, and choosing how your workload authenticates as it.
Note: Working with service accounts is gated by permissions, you will need the following:
Create service accounts. Lets you add a new service account.
Manage service account. Lets you rename it, issue and revoke its credentials, change its access, and delete it.
Get temporary credentials. Lets you mint a short-lived credential that acts as the service account.
If you don't have these, ask an admin.
Assigning tenant-wide roles to a service account additionally needs the Manage roles permission.
Create a service account
Go to members in settings to add a service account:
Select the service accounts tab and click the plus button.
Give the account a clear, purpose-based name, for example "deploy-bot." then select create service account.
You can also stage credentials during creation, but it's fine to create the account first and add them afterward. Access is always granted after the account exists.
Give it access
A new service account can't do anything until you grant it access. You grant access to a service account the same way you grant it to a person: from the resource you want it to reach. Open a space, connector, skill, or network, add the service account as a member, and choose its role. The account's access tab then shows everything it can use and its role in each.
For tenant-wide capabilities, open the service account and use the tenant roles section on its settings tab. Roles and permissions work the same for service accounts as for people, so grant only what the automation needs.
Choose how your workload authenticates
A service account supports a few ways for a workload to prove it's acting as that account. Pick the one that fits how your automation runs. You'll find each on the service account's settings tab.
API keys
An API key is a long-lived secret that lets a script or service act as the account until you revoke it. To create one, open the account, select the plus button next to API keys, name the key, and generate it.
Note: Copy it right away, because it's shown only once.
Treat a key like a password, and delete it from the account if it's ever exposed.
Temporary credentials
A temporary credential is a short-lived key that acts as the account and then expires on its own, so there's nothing to revoke afterward. This suits interactive or short-running tasks.
Select the key button next to Temporary credentials, choose how long it should last (one, four, eight, or 16 hours), and generate it. As with API keys, copy it when it's shown.
OIDC federation
Federation lets a workload, such as a GitHub Actions job, act as the account using a short-lived OIDC token from an identity provider, with no stored secret at all.
To set it up, select the plus button next to Federation, choose the identity provider, and enter the subject to trust. The subject matches the token's sub claim. You can match it exactly, or use a prefix like repo:org/repo:* to allow any branch. If no identity provider exists yet, an admin can register one first.
Turn one off or delete it
Every service account has an enabled toggle in the list. Turn it off to suspend the account without removing it.
To remove one for good, open it and use the delete action, or use the menu in the list.
Note: Deleting a service account immediately revokes its API keys, federations, and access, and it can't be undone, so make sure no automation still depends on it.