> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mountthor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Service accounts

> Manage identities for Mount Thor automation

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:

```bash theme={null}
mthr service-accounts create
mthr service-accounts ls
```

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](/platform/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.

```bash theme={null}
mthr iam roles ls
mthr iam roles get ROLE_ID
mthr iam bindings ls --service-account-id SERVICE_ACCOUNT_ID
```

The role details show the exact actions. Custom roles can contain one or
multiple admitted actions; reserved administration actions remain excluded.

Grant only the access the automation needs:

```bash theme={null}
mthr iam bindings grant --service-account-id SERVICE_ACCOUNT_ID --role-id ROLE_ID \
  --reason "CI read access" \
  --ticket ACCESS-125
```

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.
The existing `mthr service-accounts grants` commands remain available.

## Manage credentials

Issue a credential for the automation:

```bash theme={null}
mthr service-accounts credentials create SERVICE_ACCOUNT_ID
```

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:

```bash theme={null}
mthr service-accounts credentials ls SERVICE_ACCOUNT_ID
```

Rotate a credential when you need to replace it:

```bash theme={null}
mthr service-accounts credentials rotate SERVICE_ACCOUNT_ID CREDENTIAL_ID
```

The replacement secret is also shown only once. Revoke a credential when it is
no longer needed:

```bash theme={null}
mthr service-accounts credentials revoke SERVICE_ACCOUNT_ID CREDENTIAL_ID
```

## Disable a service account

Deactivate the service account when the automation is retired:

```bash theme={null}
mthr service-accounts deactivate SERVICE_ACCOUNT_ID
```

## 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:

```bash theme={null}
mthr iam bindings revoke BINDING_ID \
  --reason "Retire CI identity" \
  --ticket "ACCESS-126"
```

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](/platform/roles-and-bindings#disable-a-role-version).