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
adminon theproductionenvironment, 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
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.
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:
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.
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.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.The Scalr interface changes over time. If these steps don’t match what you see, refer to Scalr’s 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:
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.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.
Each action needs these permissions, in addition to
reports:read, roles:read, and teams:read, which every action uses:
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.
- 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.