Hierarchical Model

Note

Multiple environments are available on the paid tiers. See Scalr pricing here.

The Scalr hierarchical model is a unique feature to Scalr the helps small or large organizations enable multi-tenancy, ease overhead, and ensure security through centralized modules, vcs connections, policies and more. The Scalr account administrator has the ability to centrally manage these objects and make them available for consumption by the end users. The hierarchy is comprised of an account and environment scope(s). The environment is the child of an account, there is no limit on how many environments an account can have.

_images/hierarchy.png

There are no strict rules on how to structure environments other than that environments are a collection of related workspaces and users, but we do see some common use cases… If you’re an MSP, you can manage individual customers in each environment. If you’re a large organization, each environment can be a business unit. If you’re a smaller organization, each environment can be an application or project. Or you can have a combination of all the examples listed, the main idea is to make the overall management of objects easier and more secure.

Accounts

An account is created when a user initially signs up for Scalr. The account scope is where administrators can:

  1. Create objects that will be shared across all environments.

  2. Create and assign objects to specific environments.

Shared Objects

The objects in the table below can be created and shared across all environments from the account scope. To access these objects, go to the account scope and click on the Scalr icon:

_images/account_scope.png

Object

Description

IAM

Required. Control teams, users, services accounts, and SAML/LDAP integrations. Access policies can be assigned at the account, environment, and/or the workspace scope.

Provider Credentials

Optional. Provider credentials are created and managed at the account scope, but assigned to environments. A single credential can be assigned to one or more environments.

Environments

Required. Environments are the child of accounts. Environments are where workspaces are created and Terraform runs are executed.

Policy Engine

Optional. OPA policy groups can be created an managed at the account scope, but assigned to environments. A policy group can be assigned to one or more environments.

Variables

Optional. If a shell variable is created at the account scope, the variable will be inherited by all environments and workspaces.

VCS Providers

Optional. If a VCS provider is created at the account scope, the provider will be available to all environments and workspaces.

Modules

Optional. If a module is created at the account scope, the module will be available to all environments and workspaces.

Agent Pools

Optional. If an agent is created at the account scope, the agent will be available to all environments and workspaces.

Assigned Objects

Optionally, environments can have provider credentials, vcs providers, variables, policies, and webhooks created and assigned to them from the environments page at the account scope. Typically, an environment corresponds to functional areas, applications, cloud accounts, projects, or any grouping that is required. If any objects are assigned to the environment they can only be seen and used by users within the environment.

The objects in the table below can be created and assigned to environments from the account scope. To access this, go to the account scope, click on environments, and then the environment you want to manage:

_images/account_env_assignment.png

Object

Description

Provider Credentials

Optional. A single provider credential can be used across one or more environments. When a provider credential is assigned to an environment all workspaces in the environment will inherit the credential as a shell variable.

VCS Providers

Optional. A VCS provider is needed for the module registry and VCS connected workspaces. If a VCS provider is created here, it is only available to this environment. The VCS provider will be made available for workspaces within the envirinment, but not required if the workspace is CLI driven.

Variables

Optional. If a shell variable is assigned to an environment, the variable will be inherited by all workspaces within the environment.

OPA Policies

Optional. OPA policy groups must be created at the account scope. The policy group is then assigned to an environment.

Webhooks

Optional. If a webhook and endpoint is created and assigned to an environment, the webhook will be available to all workspaces.

Access Policies

Required. For users or teams to access an environment, they must be assigned an access policy within the environment.

Environments

Environments contain a collection of related workspaces. The objects in the table below can be created and managed within an environment:

_images/workspace_objects.png

Object

Description

Workspaces

Required. A workspace is where all objects related to Terraform managed resources are stored and managed.

Modules

Optional. If a Module is created at the environment scope, the module will be available to all workspaces within the environment.

Agent Pools

Optional. If an agent is created at the environment scope, the agent will be available to all workspaces.

Video

More of a visual learner? Check out this feature on YouTube NEWWIN.