Feature Showcase: Granular RBAC

Scalr RBAC introduces the user controls organizations need to decentralize their Terraform operations. Scalr’s RBAC design is superior to competitors in the level of flexibility it offers, with an expanded level of granularity that increases composability and decreases change management complexity.

Scalr is used today by some of the world’s largest pharmaceutical companies, international government institutions, university systems, and technology companies.

As the size and complexity of the organization grows beyond a few people, so does the burden on getting the permissions system right the first time, so that these organizations can scale their infrastructure as code practice without being overwhelmed by complexity.

For this reason, we have taken an entirely new approach to access controls, where we have designed for audit-ability, clarity, and manageability at scale. We’ve designed a system that maximizes composability, clarity, expressiveness and audit-ability while minimizing ambiguity and change complexity.

Key to our design is the implementation of RBAC within the Scalr Organizational Model. For example, a single “admin” role can be attached to a user in the account scope to give admin access to an entire account, to the environment scope to give admin access to an arbitrary collection of workspaces, or to the workspace scope to give admin access to a single workspace.

This dramatically reduces the variances of roles, making the system more robust and more manageable. In the above example, without such a system, you could easily end up with a multitude of roles such as “account-admin”, “dev-environment-admin”, “prod-environment-admin”, “myenvironment-admin”, “workspaceA-admin”, “workspaceB-admin” – a true management nightmare. And the longer that list gets, the more tempting it is to just create a new one instead of figuring out which existing one to use (and what happens when you use “dev-environment-admin” and whoever created it changes it without you knowing), which compounds the complexity.

Scalr includes a number of pre-defined system roles for common use cases, as well as the ability to define any number of custom roles. An advantage of this design is its granularity and composability. For example, administrators can create minimal roles such as “plan only” or “applies only” and compose them with other roles as needed to preserve clarity as your organization scales. The result is access controls that are understandable and unambiguous at a glance.

The last advantage of the design is its immutable roles. These are provided with an implicit promise that as Scalr functionality expands, they can be relied on to always match their intention. For example, the “read-only” immutable role promises that as we add new product capabilities, users with that role will always be able to read newly created objects.

Best Practices

Now that we’ve covered the fundamentals of the design, I’d like to share some best practices to get you started right.

Starting with a “platform admin” role is probably the most obvious first step. You can use the immutable “admin” role for easier management, or your own for more control. This is the person that will be administering the account, creating new environments and inviting teams, creating roles and setting their permissions. Over time, that person will be the one to tighten existing roles, restricting permissions to access state, to lock and unlock workspaces, to edit variables, and more, following the principle of least privilege.

After that, you’ll want to create service accounts, which is a straightforward process. They can be used to pull data from workspaces in one environment for use in another, without giving end-users access to the environment the data is coming from (in this case the service account token would be an encrypted variable in the workspace doing the pulling). More on service accounts here.

While we recommend expanding roles over time on an as-needed basis, we nevertheless recommend starting out with a plan-only role (perhaps called “developer”) and a plan & apply role (perhaps called “approver”). The first would be assigned to folks expected to write Terraform code, while the second would be for experienced reviewers.

This is easily done in Scalr:

We recommend creating environments to isolate teams working on different parts of the codebase. Environments are logical groupings of workspaces, and are useful scopes for applying policies, granting access, and more. Our recommended best practice is to equate an environment to a cloud account or landing zone, which makes it easy to visualize the isolation across your cloud ecosystem. 

You can read more about Scalr IAM in our documentation. Even better, you can use the Scalr Terraform provider to manage them. In the next blog in the series we’ll show you how to use the provider to:

• Create roles
• Create teams
• Link the roles and teams together by creating access policies at the account, environment, or workspace scopes.

‍