As mentioned in the last blog on granular RBAC, the way Scalr does IAM is a key differentiator from the competition. Scalr allows for custom roles and access policies at every scope in the product making the RBAC model extremely flexible. More flexibility and options is a good thing, but you want to make sure you're managing RBAC in a scalable way, which is done by automating it in the Scalr provider.
Automating RBAC is one step in a larger automation effort to “vend” Scalr environments, which is a best practice when onboarding new applications/teams. Typically, this involves creating a Scalr module(s) which will create teams and associate a role with the team. Then creating an environment and linking provider credentials, policies, teams, variables, and modules to the environment. This allows the teams to log into a pre configured environment and solely focus on their Terraform deployments. (If you already have a vending machine for you cloud accounts/subscriptions, you can extend that to Scalr as well) We’re going to go into some technical detail on how to automate Scalr RBAC.
There are a few objects that need to be managed:
In this tutorial, we’ll assign a team with a custom role to an environment using the Scalr provider. We are going to go through each piece of code first to help you understand how it is used and closer to the bottom of the blog you will see the end result which is a main.tf with all of the code in it.
First, let’s set up the provider in a providers.tf. Get the provider information from https://registry.scalr.io/:
Let's start constructing our main.tf. First we’ll add a local to define the account:
Next add some data sources to pull IDs:
Now, let's create a predefined set of roles that all teams will be assigned. The majority of the time, roles are created upfront and then modified as needed, this is not something that is updated frequently. For these purposes, we’ll create a role, which is used for the applications teams who need to create Terraform runs only.
Next, let’s add a team. Normally, you would likely want to use Terraform variables to reuse the code, but for these purposes we’ll hardcode and use locals for the account/environment ID. Further down in the blog you will see all of the code with the locals defined:
Lastly, we need to create an access policy to attach the role to a team and link the team to a scope in Scalr. All teams must have at least the ‘account-min-access’ role at the account scope to have access to Scalr, and then they can be added to the environment in which they will create runs:
All together, this looks like:
To execute this, you have a couple of options:
I’m choosing to use a VCS backed workspace:
Upon execution we see that the four resources have been created:
And can verify this by looking at each object in the account scope:
Account scope access policy:
Environment scope access policy:
Now that you have learned the basics of how to use the Scalr provider to manage IAM, you can take it to the next level with these few suggestions:
Look for more examples on other concepts coming soon.