Overview

Security rules in Scalr are how admins can enforce rules on the entire account. The permission security-rules:update is required to make updates to any of the security rules. All security rules can be configured at the admin level under security -> rules.

API Tokens Max Lifetime

Account admins can set maximum lifetimes for personal or service account tokens through the account security rules. The max lifetime is set in minutes and can be up to one year (525,600 minutes)

After it is set, users will not be able to set an API token lifetime higher than the limit specified:

Service Account Owner

Forcing service account owners helps reduce the risks of orphaned API tokens or unauthorized access. When enabled, this rule requires at least one owner team to be assigned during service account creation or updates, with validation preventing operations without proper ownership assignment. Account admins can activate this feature through the "Require service account owners" toggle.

Module namespace owners

Enable require owners for module namespaces under Security → Rules to require at least one team owner when creating or updating a module namespace. The rule is off by default and applies to both the UI and API, including namespaces shared with all environments.

Saving a namespace without owners is blocked with the error "At least one owner is required for module namespaces". This includes removing the last owner or updating environment access on an ownerless namespace. The blocked save is recorded as a failed action in the audit log.

Existing ownerless namespaces and their modules remain available after the rule is enabled. The namespace list flags them, and namespace settings show a compliance warning until an owner is assigned. Add an owner team in the namespace's General tab before saving changes.

Users with security-rules:update can disable the rule to allow ownerless namespaces again. Changes to the rule are recorded in the audit log.

Provider configuration owners

Enable require owners for provider configurations under Security → Rules to require at least one team owner on every provider configuration. The rule is off by default and applies to saves from the UI, the API, and the Scalr Terraform provider. It also applies to configurations shared with all environments.

When the rule is on, any save without an owner fails with "At least one owner is required for provider configurations." This includes updates that remove the last owner and edits to an existing ownerless configuration that don't add an owner. Blocked saves appear as failed operations in the audit log.

Existing ownerless configurations keep working in runs. The provider configuration list and settings page flag them as noncompliant until you assign an owner in the Owners tab. After you disable the rule, you can save ownerless configurations again. Changes to the rule are recorded in the audit log.

Enforce Execution on Self-Hosted Agents

Admins can enable a security rule that requires all workspaces to run on self-hosted agents. When enabled, all new and existing workspaces must have a self-hosted agent pool configured to execute runs or save workspace updates.

If users try to execute a run without a self-hosted agent set in the workspace, it will error:

Workspaces cannot be updated until the self-hosted agent is set in the pipeline settings:

Workload Identity Policies

Assume policies let a workload identity (for example a GitHub Actions or GitLab CI OIDC token) assume a service account. By default, a policy can be built from any combination of claim operators, including broad ones such as contains or like with wildcards.

When Require an exact-match "eq" condition in assume policies is enabled, every assume policy must include at least one eq condition on a claim other than aud or iss. Other operators (startswith, endswith, contains, like) can still be combined with it to narrow the match, but they are not enough on their own. The aud and iss claims do not count, because they are the same for every token from a given provider.

With the rule enabled:

• Creating or updating a policy without a qualifying eq condition fails with: At least one claim condition must use the 'eq' operator on a claim other than 'aud' or 'iss'.
• Existing policies are not modified, but a policy without a qualifying eq condition is skipped when a token is exchanged. If no other policy matches, the exchange is rejected with a 401.
• Turning the rule off again makes those existing policies usable without any edits.

Example of a valid combination: email eq [email protected] together with sub startswith 1121.