Skip to main content
Use service accounts for CI pipelines, scheduled jobs, and other automation that needs to access Mount Thor. A service account is separate from a person: it has its own access assignments and credentials. Use your normal Mount Thor login to manage service accounts. Give the issued credential to the automation that will use it, and store it in a secret manager.

​
Create a service account

Create a service account and list the service accounts in your tenant:
Mount Thor assigns an ID to each service account. Keep that ID with the automation it represents.

​
Give the account access

Use Roles and bindings to create a custom role and assign it with mthr iam. Sign in as an active tenant owner. Choose an enabled custom role belonging to the same tenant as the active service account. Built-in roles, including Owners, cannot be assigned to service accounts.
The role details show the exact actions. A custom role can contain one or more actions, but not reserved administration actions. See Actions for the actions a custom role can include. Grant only the access the automation needs:
Grant and revoke require nonblank reason and ticket values for your organization’s audit records. Save the returned binding ID, or find it with bindings ls. A new role version does not change existing assignments.

​
Manage credentials

Issue a credential for the automation:
The credential secret is shown only once. Store it immediately in a secret manager, and never commit it to source control or print it in build logs. List credentials associated with a service account:
Rotate a credential when you need to replace it:
The replacement secret is also shown only once. Revoke a credential when it is no longer needed:
A credential is valid for 90 days, and a service account can hold two at a time. After a rotation, the credential it replaces keeps working for 10 minutes so you can switch over.

​
Use a credential

Send the credential as a bearer token to the Mount Thor API at https://customer-api.mountthor.com. The secret starts with mt_sa_v1_.
The request succeeds only if the service account’s roles grant the permission the operation needs. The API reference lists the permission for each operation. Service accounts can list, create and delete virtual machines and bare-metal machines, manage event subscriptions, and call the billing and account operations their roles allow. On an account with customer-managed compute, see Service accounts there. Managing members, credentials, roles and bindings needs a person’s session. To run mthr as the service account, save the credential as JSON and point the CLI at the file:
With this variable set, mthr bm and mthr vm support ls, create and delete. Other commands are refused until you unset it. On an account with customer-managed compute, mthr 0.3.81 and later run whoami, bm ls, bm get and bm report instead. See Customer-managed compute.

​
Disable a service account

Deactivate the service account when the automation is retired:

​
Revoke access

Copy the binding ID from the direct-grants list returned by mthr iam bindings ls --service-account-id SERVICE_ACCOUNT_ID, then revoke that assignment:
Other active bindings may still grant the same actions. Review effective access afterward. To retire a role version for every member and service account bound to it, use role disable.