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

# Scalr

> Connect a Scalr account to Oleria to discover users, teams, roles and their access to environments and workspaces, service accounts, API tokens, OIDC trusts, provider configurations, stored secrets, and run activity, and take remediation actions directly from Oleria.

Scalr is a Terraform and OpenTofu automation platform. Connect a Scalr account to Oleria to see who belongs to it, which teams they're in, which roles they hold on the account, its environments, and its workspaces, and which service accounts, tokens, and cloud credentials can act in it. Oleria reads this data from the Scalr API with a service account token. You can then review over-provisioned access and take action directly from Oleria.

One Oleria integration covers one Scalr account. To connect another account, add another integration.

## What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Scalr account:

* **Accounts** - every user in the account, with name, email, username, status, when they were invited, and when they last signed in. The account owner and users with full access to the account are marked as administrators. Each user's account role is the broadest role they hold at the account scope. Oleria also shows how each user can sign in: password, SSO, or a personal access token they own.
  * **SSO** - when the account signs in through SAML or LDAP, users are shown with SSO required. Users on the account's SSO bypass list are shown with SSO configured and password sign-in.
  * **Pending invitations** - users who haven't accepted their invitation are shown as disabled until they do.
* **Teams** - every team appears as a group, with its members.
* **Roles** - Scalr grants a role at a scope: the account, an environment, or a workspace. Oleria shows each role at each scope where it's granted as a separate role, for example `admin` on the `production` environment, along with the users, teams, and service accounts that hold it and the resource it grants access to. Both system roles and custom roles appear. A role granted on the account also reaches every environment or workspace its permissions cover, including ones created later, so Oleria links it to the **Scalr environment** or **Scalr workspace** resource type with just those permissions.
* **Resources** - the account, its environments, and their workspaces, as a hierarchy. The account is linked to its owner.
* **Non-human identities (NHIs)**:
  * **Service accounts** - with status, the user who created them, their owner teams, and when one of their tokens was last used.
  * **Service account tokens** - linked to their service account, with creation date, expiry, and last-used date. Scalr tokens have no scopes, so each token has the full access of its service account.
  * **Personal access tokens** - linked to the user who owns them, with creation date, expiry, and last-used date.
  * **Agent pools** and their **agent pool tokens**, with the user who created each token. Oleria skips the agent pools Scalr manages itself.
  * **Agent mTLS certificates** - linked to their agent pool, with fingerprint and expiry.
  * **MCP connections** - AI clients connected to Scalr's MCP server, linked to the user who authorized them.
  * **OIDC trusts** - the assume policies that let an external OIDC provider, such as GitHub Actions, act as a service account. Each one shows its issuer, audience, and subject claim, and is linked to its service account.
  * **Provider configurations** - the cloud credentials Scalr uses to run Terraform and OpenTofu, shown by type, such as access key, OIDC federation, client secret, or service account key. Each one is linked to its owner teams.
* **Secrets** - shown as credentials: VCS provider tokens, SSH keys, sensitive variables and sensitive variable set variables, the API keys and passwords of Datadog, Infracost, Wiz, and Docker integrations, and the Azure AD client secret of a SAML integration. Oleria never reads secret values.
* **Activity** - Scalr runs:

  * a run being queued, with the user or service account who started it
  * a user confirming, discarding, or canceling a run, or overriding a policy check

  Each event shows the workspace it ran in. Runs started by Scalr itself are shown with a **Scalr system** machine account as the actor.

Oleria refreshes users, teams, roles, resources, and NHIs on its [regular sync schedule](/integrations/overview.md#sync-model).

> [!NOTE]
>
> Oleria doesn't import Terraform state, modules, policies, variable values, or run plans and logs.

## Prerequisites

* A Scalr account on any plan, including the Free plan. Agent mTLS certificates appear only on plans that offer agent mTLS enforcement.
* A Scalr account administrator, to create the role, the service account, and its access policy.
* Admin access to the Oleria workspace.

> [!NOTE]
>
> Use a service account token, not a personal access token. A service account token keeps working when people leave, and you can see and limit exactly what it can do.

### Permissions

A Scalr token has exactly the access of the roles its service account holds. Create a custom role with these permissions and grant it to the service account at the **account** scope:

| Permissions | Used for |
| :- | :- |
| `accounts:read`, `users:read`, `teams:read`, `roles:read`, `reports:read` | Users, teams, roles, access policies, and personal access tokens. Required. |
| `environments:read`, `workspaces:read` | Environments, workspaces, and run activity. Required. |
| `service-accounts:read`, `agent-pools:read`, `workload-identity-providers:read` | Service accounts, their tokens, agent pools, and OIDC trusts. |
| `cloud-credentials:read` | Provider configurations. |
| `integrations:read` | SAML integrations, MCP connections, and integration secrets. |
| `vcs-providers:read`, `ssh-keys:read`, `variables:read`, `var-sets:read` | VCS provider tokens, SSH keys, and sensitive variables. |

For discovery only, you can grant the system `read-only` role instead. Don't grant the `admin` role or any role with `*:*`.

To let Oleria take remediation actions, add the permissions each action needs to the same role. See [Remediation actions](#remediation-actions).

When you connect, Oleria checks that the token reaches exactly one Scalr account, the one your account URL names, and can read its users, teams, roles, access policies, environments, and workspaces. A token that reaches more than one account, such as a personal token of someone in several accounts, is refused: use a service account token, which belongs to exactly one account. A missing permission for any other object type doesn't block the connection: those objects are left out of the sync until you add the permission.

## Set up access in Scalr

**1. Create the role**

Sign in to Scalr as an account administrator. At the account scope, select **Security** -> **IAM** -> **Roles**, and create a role named `oleria-connector` with the permissions in [Permissions](#permissions).

**2. Create the service account**

Select **IAM** -> **Service accounts** -> **New service account**. Enter a name such as `oleria` and a description. If your account requires service account owners, select an owner team.

**3. Grant the role at the account scope**

On the same form, select **Grant access**. Set **Grant on** to **Account**, select the `oleria-connector` role, and confirm. Then select **Create**.

**4. Generate the token**

On the service account's page, find **Tokens** and select **Generate token**. Enter a description such as `Oleria`, and choose an expiry that fits your rotation policy. Copy the token right away. Scalr shows it only once.

> [!NOTE]
>
> The Scalr interface changes over time. If these steps don't match what you see, refer to Scalr's [Identity and Access Management](https://docs.scalr.io/docs/identity-and-access-management) documentation.

## Connect Scalr to Oleria

**1. Open the integration**

Sign in to your Oleria workspace, navigate to **Integrations**, and select **Scalr**.

**2. Complete the connection form**

Fill in the connection form:

| Field | Notes |
| :- | :- |
| Scalr account URL | Required. The address you use to sign in to Scalr, for example `https://acme.scalr.io`. The account name alone, such as `acme`, also works. Only `scalr.io` addresses are accepted. |
| API token | Required. The service account token you generated. |

**3. Authenticate**

Select **Authenticate**. Oleria checks that the token is valid and reaches exactly one Scalr account before it saves the integration. The integration is named after your Scalr account.

### Edit the connection

You can replace the **API token** of an existing integration, for example when you rotate it, or correct the **Scalr account URL**. The token must still belong to the same Scalr account. To connect a different account, add a new integration.

## Verify the integration

Confirm the Scalr integration appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, check that users, teams, roles, environments, workspaces, and NHIs appear in your Oleria workspace, and that the account owner is marked as an administrator.

> [!NOTE]
>
> When the token expires or is deleted, discovery stops. Generate a new token on the same service account and enter it by editing the integration.

## Remediation actions

Oleria runs actions with the integration's token. Before an action runs, Oleria checks that the token's roles grant the permissions the action needs, and names any that are missing.

| Action | What it does | Revert |
| :- | :- | :- |
| Disable user accounts | Sets the user's status to **Inactive**. | Supported - restores the user's previous status. |
| Enable user accounts | Sets the user's status to **Active**. | Supported - restores the user's previous status. |
| Add user to group | Adds the user to a team. | Supported - removes the user from the team. |
| Remove user from group | Removes the user from a team. | Supported - adds the user back to the team. |
| Add user to role | Grants the role at its scope to the user or service account. Oleria adds the role to the subject's existing access policy at that scope, or creates a new access policy. | Supported - removes the role again. |
| Remove user from role | Removes the role at its scope from the user or service account. An access policy left without roles is deleted. | Supported - grants the role again. |
| Revoke access to resource | Deletes the user's or service account's own access policies on exactly that account, environment, or workspace. Oleria reports access that remains, such as roles held on a broader scope or through a team. | Supported - grants each removed role again. |
| Create user | Invites the user by email into one or more teams. Choose at least one team. The user sets their name and password when they accept. | Supported - cancels the invitation, or removes the user from the account. |
| Create group | Creates an empty team. | Supported - deletes the team, while it still has no members and no access policies. |
| Delete user | Removes the user from the account. Their access policies and team memberships are removed with them. | Not supported. |
| Disable NHI accounts | A service account is set to **Inactive**. A service account token, agent pool token, or personal access token is deleted. An MCP connection is terminated. An OIDC trust is deleted. An agent mTLS certificate is revoked. | Supported for service accounts only - sets the service account back to **Active**. Deleted tokens, trusts, and connections and revoked certificates can't be restored. |

Each action needs these permissions, in addition to `reports:read`, `roles:read`, and `teams:read`, which every action uses:

| Action | Required permissions |
| :- | :- |
| Disable user accounts, Enable user accounts | `users:update` |
| Add user to group, Remove user from group | `teams:update` |
| Add user to role, Remove user from role, Revoke access to resource | `accounts:set-access-policies`, `environments:set-access-policies`, `workspaces:set-access-policies`, for the scopes you change |
| Create user | `users:create`, and `users:delete` to revert |
| Create group | `teams:create`, and `teams:delete` to revert |
| Delete user | `users:delete` |
| Disable NHI accounts - service account | `service-accounts:update`, and `ownership:bypass` for a service account owned by a team |
| Disable NHI accounts - token | `access-tokens:delete` |
| Disable NHI accounts - MCP connection | `integrations:manage` |
| Disable NHI accounts - OIDC trust | `service-accounts:update` |
| Disable NHI accounts - agent mTLS certificate | `agent-pools:update` |

Oleria refuses these actions and sends no change to Scalr:

* Any action on the integration's own service account or token. Oleria finds them in Scalr's API token report. If it can't identify them, it refuses every action rather than risk disconnecting the integration.
* Changing the account owner's status, deleting the owner, revoking the owner's access, or removing the owner from a team or role. You can still add the owner to a team or role, and revert that action.
* Removing a role the user holds only through a team. Remove the user from the team instead.
* Changing a system access policy, or the members of a team that an identity provider manages when the account doesn't have SCIM provisioning. Scalr ignores those changes, so make them in the identity provider.
* Running **Disable user accounts** or **Enable user accounts** on a user who hasn't accepted their invitation. Use **Delete user** to cancel the invitation.
* Running **Enable user accounts** on a user whose membership in this account a Scalr admin deactivated. Re-activate the membership in the Scalr UI. **Disable user accounts** on such a user succeeds without a change.
* Disabling an agent pool or a provider configuration. Scalr can only delete them, which would break runs. Delete their tokens or the cloud credential instead.

Keep these points in mind:

* If the target is already in the requested state, the action succeeds without making a change, and there's nothing to revert.
* A Scalr user is one identity across every Scalr account they belong to. **Disable user accounts** changes that identity's status, so it can also affect the user's access to other Scalr accounts.
* **Delete user** and **Revoke access to resource** remove access policies. A reverted grant comes back as a new access policy.

## Known limitations

* **No MFA or password-change data.** Scalr's API doesn't report whether a user has turned on two-factor authentication or when they last changed their password. MFA is shown as unavailable for every user.
* **Activity is limited to runs.** Scalr's audit log is an Enterprise add-on that streams events to Datadog, AWS EventBridge, or storage, with no API to read it. Sign-ins, setting changes, and IAM changes don't appear as activity. Approvals made more than three days after a run was queued are picked up only when Oleria reads earlier activity.
* **Webhook secrets aren't inventoried.** Scalr doesn't say whether a webhook has a secret.
* **Token scopes aren't available.** Scalr tokens have no scopes. Every token has the full access of the service account or user that owns it.
* **Some objects depend on the plan.** Agent mTLS certificates and team membership managed by SCIM need a Scalr plan that offers them. On other plans they don't appear.
* **Some behavior isn't confirmed on a live account yet.** Disabling and enabling users, deleting personal access tokens, terminating MCP connections, revoking mTLS certificates, SSO status for SAML and LDAP sign-in, and some secret types have been tested against Scalr's API documentation, not a live account. If something doesn't match what this page describes, contact us.

## Contact us

For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.