Service accounts
A service account is a non-human identity. Assign it to a workflow with Runs as, share resources with it, and disable it to stop every run that uses it.
A service account is an identity that a workflow runs as. It has its own grants, so what an unattended run can reach does not depend on the person who happened to create the workflow.
There are two kinds.
| Kind | What it is |
|---|---|
| Project default | Every project has one. It is created with the project and cannot be renamed or deleted. It shows as Default with the project name. |
| Named | An account you create, with a name you choose. |
Creating one
Open Service Accounts in the sidebar, at /helios/service-accounts, and choose New service
account. Rename it inline to something that says what it is for, such as "nightly-digest".
Each account has a detail view with two lists.
- Used in shows the workflows that run as this account.
- Has access to shows every grant the account holds.
Giving it access
A new named account has no access. Share the integrations, projects, and
Library paths the workflow needs with the account, at the lowest role
that works. An integration shared at operator is enough for an agent to call it.
You can also add a service account to a group and share with the group.
Runs as
On a workflow page, the Runs as control shows which account the workflow uses. Open it to pick Project default or any named account you can assign, or follow Manage service accounts to the accounts page.
When the run starts, the agent gets exactly the service account's access.
Disabling an account
Each named account has a switch that disables it. A disabled account cannot start runs. Workflows that run as it fail until the account is enabled again. Use this to stop an automation quickly without editing every workflow.
Sharing the account itself
A service account can be shared at viewer or admin, with people or groups but not org-wide.
admin lets someone rename, disable, or assign the account and change its identity settings.
Act as me
Some integrations need a person's own authorization. Today that is GitHub on organization installs and Slack. A run under a service account would normally stop with "authorization required" on those.
The Identity section on a named service account has an Act as me switch. Turn it on and the account uses your GitHub or Slack authorization when a run calls those integrations. Actions appear as you.
- You can only point a service account at yourself. Nobody can make it act as a teammate.
- Only admins of the service account can change the switch.
- Project default accounts do not have this section.
The other way to avoid "authorization required" is to share the integration with the account using the Helios app identity. See credential mode.
From the CLI
helios service-account list
helios service-account create nightly-digest
helios service-account assign nightly-digest <workflow-id>
helios service-account unassign <workflow-id>
helios service-account disable nightly-digest
helios service-account enable nightly-digest
helios service-account delete nightly-digestassign sets Runs as for the workflow. unassign puts it back on the project default.
Related
Last updated on
Groups
A group is a named set of people and service accounts. Share a resource with the group and every member gets the role.
Credential mode
When you share an integration, choose whether the grantee's agents call it with their own authorization or with the Helios app identity. This matters for GitHub and Slack.