Scalr ACLs: Creating IAM Policies Across Clouds

April 13, 2017 Alexander Green

IAM policies are documents that state permissions for a particular resource - whether this is an entire cloud service like GCP BigQuery or the ability to spin up instances inside AWS EC2. Each cloud provider has their own way of managing IAM, but typically they work the same. Users can be assigned permissions directly, on their team, or based on the environment they are working in.


Some examples - only one team of users (DevOps) should have access across all applications and environments. Or within a specific team, only senior developers can terminate production servers. How about if you want front end developers to have read-only access to RDS?


IAM policies abstract away the resources users don’t need to interact with and empower them with the ones they do. But there’s one problem - policies are siloed off in separate cloud providers. In the modern enterprise environment, we don’t live in one cloud provider. We also don’t rely on one third party integration, or use a single analytics tool for all our data. With new tools and services coming out across cloud providers, the battle to maintain control gets exhausting. Should admins micromanage access control?


Scalr, as a cloud management platform, uses our abstraction across cloud providers as a solution to this problem. Setting IAM policies independent of clouds means managing your users and sanity from one location.


Here’s how the Scalr hierarchy works:

image01-3.png

It’s a top down management system. Set policies at the Corporate Scope, and they pass down to the individual applications inside Environments. Set policies on an Account scope, and they influence all users and infrastructure inside it. Set policies on an Environment, and they only affect the farms (applications) inside it.


Accounts contain teams of users and the Environments that teams have access to. Environments are logical grouping of resources. This includes Farms (our terminology for applications), scripts, server images, containers, cloud services and third party integrations. Here’s the beautiful thing: you add your cloud credentials at the Account level, so your infrastructure inside Accounts are not isolated by their original cloud.


Let’s use an example - more show, less tell. I have a business unit (Account) called Scalr Digital. Inside the Scalr Digital Account we have a Development Environment, a Staging Environment, and a Production Environment. We have one flagship web application: Bluebook. The application has a web server, a database, and a load balancer (in Scalr, these components of an app are called Roles).


All users have free reign in the Development Environment. You can create new testing servers at will (but admins can limit the instance sizes and lifecycles). You can change instance sizes and security groups, access SSH keys, and so on.


On the other hand, The Staging Environment is for manual testing and production prep, so only limited members can manage staging infrastructure. Everyone can look, but few can touch.


The Production Environment is the real deal, our live environment with real users. Because of that, only admins and DevOps should have the ability to do anything in this Environment.


Great examples. How can we make them happen?


First, let’s take a look at the list of teams at the Account level. Here are the teams inside Scalr Digital.


image05.png

Here’s my DevOps team - Scalr Ops. In Access To, we can see all of the environments they have access to within the Scalr Digital Account.


On the Default ACL, we can see the default permissions the team has. Full Access means all users in this team can do anything in the Environments they have access to.


ACLs (access control lists) are the way that Scalr makes IAM policies work across clouds. ACLs allow us to specify the items in the UI that users can change, interact with, or even see. In other words, “guardrails” for users while they’re working on the organization’s cloud infrastructure.


Here’s the list of everything you can set on an ACL:

image00-4.png

Lot of options. We can manage anything from the components of an application (via Roles), to the handling of abandoned resources using the Garbage Collector. Notice how apart from control on servers, services, and security, you can use also use ACLs to get detailed on resources from specific cloud providers.


Let’s look at one of these options - some permissions around AWS:


image06.png

image10.png

 

The DevOps team in Scalr Digital can manage S3 buckets, create snapshots, manage elastic IPs and plug into CloudWatch. For a different team in a different environment, we can configure exactly what they access.


Here I’m allowing DevOps to import images into any Environment and manage them as necessary. They also have the power to completely manage Farms (applications).


image07.png

This is the power of Scalr - the ability to get granular for the services within your cloud providers, but also set overarching policies over your teams and the infrastructure they use.


So let’s create a Team of the developers for Bluebook and create two ACLs for them. One is for the Production Environment. I want them to view almost everything (read only), but change little. Also, because Permissions are scoped, which means users can have different permissions across Environments, we’ll create another ACL which gives them full access in the Development Environment.

image08.png

 

Let’s create our first ACL for them.


image09.png

 

They can see the scripts we use in the Production Environment (which range from onboarding Chef nodes, installing Datadog monitoring, etc.). They can’t change the scripts, but they can fork them and change the forked versions. We also don’t want them to access SSH keys for the servers and we don’t want them changing security groups. They can view statistics on Production farms, but they can’t stop the servers or spin up new ones.

So now that we have created this ACL for our Team - Bluebook Developers, we can grant the team access to the Production Environment.

image04-1.png

For the Development Environment, I’ll do the same thing and give the team access, but set their ACL on this environment with a generic ‘full access’ ACL.

image02-2.png

And that’s it! This was a quick summary on SCALR ACLs - the best way for admins to authorize users on specific resources, giving you full control and visibility to manage resources across cloud providers. Scalr also provides built-in auditing for compliance. Our goal is to improve cross-cloud cloud resource optimization.


For more information, visit the wiki:

https://scalr-wiki.atlassian.net/wiki/display/docs/Role-Based+Access+Control


Or check out videos and webinars on our resource hub for more details on Scalr ACLs and other features.

http://hub.scalr.com/webinars

Previous Article
How to Build a CI/CD Pipeline with Jenkins & Scalr [Webinar Summary]
How to Build a CI/CD Pipeline with Jenkins & Scalr [Webinar Summary]

Building A CI/CD Pipeline was one of our highest performing webinars - letting us know that developers and ...

Next Article
Scalr ACLs: Creating IAM Policies Across Clouds
Scalr ACLs: Creating IAM Policies Across Clouds

IAM policies are documents that state permissions for a particular resource - whether this is an...

×

Join thousands of Cloud professionals on the Scalr Newsletter

Thank you!
Error - something went wrong!