Identity and Access Management

The Scalr IAM is a Role Based Access Control (RBAC) system that controls access to all functionality in Scalr. First, please review the terminology used in Scalr IAM:

Term	Description
Object	The target of permissions, e.g. environment, workspace, runs, state-versions etc.
Permission	The ability to perform an action on an object, thus enabling the corresponding functionality in the UI. API etc. e.g. workspaces:create, vcs-providers:read. Generally the actions are Create, Read, Update and Delete (CRUD), but some objects have specific actions, such as runs:cancel.
Role	A collection of permissions that can be assigned to a user or team via an access policy.
Access Policy	Grants a role to a user/team for the whole account, a specific environment or a specific workspace.

IAM Summary

Access is granted by creating an access policy and linking a user/team to a role. All users must have a role with at least account-min-access assigned to an account scope access policy to be able to access their Scalr account.

• Account access policies can grant permissions to the account. Permissions to all environments and workspaces in the account can also be granted if the proper permissions are set.

• Environment access policies can grant permissions to the specific environment. Permissions to all workspaces in the account can also be granted if the proper permissions are set.

• Workspace access policies can grant permissions to the specific workspace only.

• A user/team can be granted multiple access policies for the account, environments and workspaces. The permissions from all the applicable roles will be applied when multiple access policies exist.

This graphic shows how access policies assign roles to the account and environment or a workspace for users and teams.

Roles

There are two types of roles in Scalr. Built-in “system” roles have been pre-created, thes are common roles that are generally used. There are also custom roles, which allow you to create a role with your own set of permissions.

System Roles

Scalr has a set of predefined roles as follows.

Role	Description	Applicable to
account-min-access	Minimum permissions required to be able to login to an account.	Account only.
admin	All permissions for all objects.	Account and environment.
environment-min-access	Minimum permissions required to be able to login or switch to an environment. Any user that needs access to an environment must have this policy assigned.	Account and environment.
read-only	Read only access to all objects.	Account and environment.
user	Full access to all objects in environments and READ ONLY access to account objects (teams, users etc).	Account or environment.

Some built-in roles include permissions for account objects, environment objects and workspace objects. When a role is applied only the permissions applicable to the objects in the current context are active.

Custom Roles

Note

Roles can be created and managed as code through the Scalr Terraform Provider.

If the built-in roles do not meet requirements then custom roles can be defined for an account.

• On the IAM -> Roles screen click “New Role” and give the role a name.

• Use the checkboxes to select/deselect the permissions and click “Save”.

Access Policies

Note

Access policies can be created and managed as code through the Scalr Terraform Provider.

Access policies can be granted on accounts, environments and workspaces. Access policies link users/teams to a role.

• Account access policies can grant permissions to the account and to all environments and workspaces in the account.

• Environment access policies can grant permissions to the specific environment and all its workspaces.

• Workspace access policies can grant permissions to the specific workspace only.

If multiple access policies are applicable the user/team will have the combined permissions (logical AND) from all of them. An individual access policy cannot revoke permissions granted by another access policy. For example if one applicable access policy grants full access to VCS Providers, but the another applicable access policy only grants vcs-providers:read the user/team will still have full access to VCS providers.

Account access policies are managed under the access policies section of IAM.

Use account access policies to grant permissions on the account and all environments and workspaces in the account. Only use account access policies if it is intended to give users the same permissions to all environments and workspaces.

Environment access policies are managed from the access policies tab on the environments screen.

Use environment access policies to grant permissions on specific environments. Users will have the same permissions to ALL workspaces in the environment.

• In the account go to environments and select the access policies tab for the environment.

• Click grant access and select the user/team and role.

Workspace access policies are managed from the access policies tab of a workspace.

Use workspace access policies to grant permissions to one specific workspace. If you intend to give a user/team the same permissions to all workspaces in an environment then use an environment access policy instead.

Role & Access Policy Examples

All users require an account access policy with the role that has accounts:read permission. All users that need to login to an environment must have an access policy that has ``environment:read` permission.

A team requires read only access to all environments in the account.	Create an account access policy with the role environment-min-access. Create an account access policy with the role account-min-access.
A user requires full access to all environments in their account.	Create an account access policy with the role user.
A team requires full access to a specific environment.	Create an environment access policy with role user. Create an account access policy with the role account-min-access.
A team requires read only access to the account.	Create an account access policy with the role read-only.
A user needs full access to only one workspace.	Assign account-min-access to a team/user as an account access policy. Assign environment-min-access to a team/user as an environment access policy. Assign user to a team/user as the workspace access policy.
A user requires access to one workspace to read plan outputs and state files.	Assign account-min-access to a team/user as an account access policy. Assign environment-min-access to a team/user as an environment access policy. Create a custom role with permissions plans:read-json-output, state-versions:read, workspaces:read. Create a workspace access policy with the custom role.

Adding Teams & Users

Teams

Teams configured in the account and can be used to assign access policies to multiple users.

Inviting Users

Users are also managed in the account. Account owners and admins can invite users and either add them to a team or assign them to a role individually. Assigning a role in this way will create an account access policy for the user that gives them the role permissions for the account and all environments in the account.

Single Sign-On

Note

Scalr supports multiple methods of SSO including Google and Github auth. To use a provider other than Google and Github, you must upgrade to a paid tier. If you want to configure SSO on a self-hosted installation, please see External Authentication.

Configuration

Scalr support SSO providers that use SAML 2.0. When SSO is activated, it will move the authentication step outside of Scalr and hand it over to the SSO provider that you have configured. During the login in to Scalr, the user will be transferred to a sign in page provided by the SSO server. After sign in, the user will then be redirected back to Scalr which will subsequently treat the user as signed in.

To enable SSO, you must configure it at the account scope of the Scalr UI. To do this:

1. Click on the Scalr icon on the top left, click IAM, and then SSO:

   

2. Click on Identity Providers, New Identity Provider, and then choose SAML or Import SAML metadata. When using Import SAML metadata, most SAML providers will provide a metadata file which can be uploaded into Scalr for an easy configuration on the Scalr side. If the provider does not provide the metadata file, choose SAML. Note down the SP endpoint as that will be used with the SSO provider. For example: https://scalr-account.scalr.io/public/saml/idp-sp986542njcvhj123?metadata and https://scalr-account.scalr.io/public/saml/idp-sp986542njcvhj123?acs

3. Go to your SAML provider and start the configuration (see below for examples). The Scalr setup can be finished upon completion of the SAML provider configuration.

4. Uploade the metadata file or manually fill in the fields required by your SSO provider and verify the connection when prompted.

5. After you save the configuration, turn on the SSO authentication by selecting the SAML provider in the dropdown:

   

Okta Example

Note

Scalr supports all SAML 2.0 providers, this is just an example of a commonly used one.

1. Create an application by clicking Applications, then Applications, and Create App Integration:

   

2. Select SAML 2.0 in the “Create a new application integration” dialogue message:

   

6. Enter the “App name”, then select Next:

   

7. Configure SAML settings. Fill in the form as shown in the example below.

• The “Single sign on URL” is your SP endpoint, but with ?acs instead of /metadata at the end. Example: https://example.scalr.io/public/saml/idp-tl2g4mu9v47a111?acs

• The “Audience URI (SP Entity ID)” is your SP endpoint. Example: https://example.scalr.io/public/saml/idp-tl2g4mu9v47a111/metadata

  

• Ensure the “Group Attribute Statements (Optional)” field is populated in order for the user groups to be sent to Scalr correctly. It’s extremely important to correctly enter the “Attribute name”, “Format”, and “Filter” option as shown below:

  

8. Finishing the SAML integration:

   

9. When complete, you will be forwarded to a Sign On page where the SAML Service Provider configuration options link can be found. Click “View Setup Instructions” to see details:

   

10. You can either upload the metadata to Scalr or manually enter the following. If the manual entry is being done, the following settings in to the SAML setup in the Scalr UI. Be sure to use the ID and URL that you obtained previously:

• idp entity_id => http://www.okta.com/exk8ldhenajn8ckSdgh6

• idp single_sign_on_service url => https://scalr.oktapreview.com/app/scalrincdev369882_scalr_1/exk8ldhenajn8ckS40h7/sso/saml

• idp x509cert => —–Cert Goes Here—–

11. Click save and you will now see the SSO option in Scalr upon the next login.

Azure AD SSO Example

Note

Scalr supports all SAML 2.0 providers, this is just an example of a commonly used one.

1. Go to Azure Active Directory and click on Enterprise applications:

   

2. Select New application and Create your own application:

   

3. Name the application and select “integrate any other application you don’t find in the gallery”:

   

4. Select “Set up single sign on”:

   

5. Click edit on the Basic SAML Configuration option and enter the following:

• Identifier = SP Endpoint from Scalr

• Reply URL = FQDN of the Scalr endpoint

• Sign on URL = the Scalr FQDN with /public/saml?acs at the end of it (i.e. https://my-account.scalr.io/public/saml?acs)

• Click save

  

6. Open the User Attributes & Claims, click add new claim, select “All groups”, and save:

   

7. On the Single sign-on page, go to the SAML Signing Certificate section and download the Certificate (Base64). Paste that into the IDP x509cert section in Scalr:

Azure:

Scalr:

8. On the Azure Single sign-on page, go to the Set up <your app name> section:

• Login URL = the IDP single sign on service URL in Scalr

• Azure AD Identifier = the IDP entity ID in Scalr

• Logout URL = the is the IDP single logout service URL in Scalr

Azure:

Scalr:

9. In Azure, go to App registrations, find your app and click on it. Copy the Application (client) ID and Directory (tenant) ID, paste the IDs into the respective fields in Scalr:

Azure:

Scalr:

10. In Azure, click on Certificate & Secrets and generate a Client secret. Paste the secret into the respective field in Scalr:

Azure:

Scalr:

11. In Azure, click on API Permissions. Add a permission, select Microsoft Graph, Application permissions, and add Directory.Read.All. Ensure that “admin consent” is set to yes and the permission type is “application”.

    

12. In Scalr, add the following settings in the mapping section:

• Groups = http://schemas.microsoft.com/ws/2008/06/identity/claims/groups

• Email = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

• Fullname = http://schemas.microsoft.com/identity/claims/displayname

  

13. In Scalr, click on the advanced section and update the following fields:

• IDP single sign on service binding = urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

• SP name id format = urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

  

14. Click save and you will now see the SSO option in Scalr upon the next login.

Users and Teams with SSO

After Scalr has been reconfigured for SSO, users and teams work as follows.

1. Teams map to SSO groups. Account admins have access to create teams in Scalr and the team name will be validated against the groups in SSO, so the team name must match the group name.

2. Teams must linked to at least one environment and account.

3. Once a team has been linked and given the proper permissions, any member of the related SSO group can attempt to login to Scalr. On first login a user record gets created in Scalr and set as SSO authenticated.

Break Glass Users

Incidents happen and it is likely that, at some point, your SSO provider will have an outage. If this happens, you can avoid being locked out of Scalr through the “break glass” feature. This feature allows you to specify a list of users who are exempt to SSO log in the event of a SSO outage. These users can be specified directly on the SSO page:

Service Accounts

A service account in Scalr is a local user that can be created, even if LDAP or SAML is enabled, to allow external services to call Scalr without the API token being linked to a named account. It is best practice to avoid using an employee or user API token to integrate with Scalr in the event the employee or user leaves the company. The service account will always remain active unless updated by an administrator.

To create a service account, go to the account scope, click on IAM, and then service accounts. To generate and manage existing API tokens for the service account, click on the gear:

The permissions for a service account are granted the same way permissions are granted for users and teams. Please see the instrcutions above.