Compliance is hard in the cloud. We have to be aware of where our data is located, how it’s secured on different cloud providers, and who has access to it. The same goes for the applications using that data and the infrastructure that managing it all.
Compliance is essential for enterprises, especially where sensitive user data is at risk. You have to enforce policies on networks, server tags, storage encryption, key management and more. Depending on your industry, compliancy can also involve maintaining patient data privacy for HIPAA or ensuring the encryption of financial data as per SEC regulations. And not just that – it’s maintaining that compliance across your different business units and applications.
In the end, what we worry about is customer data getting exposed and unauthorized access of our applications and infrastructure. So the solution is building out a framework to ensure that there’s no gaps exposing our users and resources.
But how do you do it?
There’s solutions inside each cloud provider. In AWS, you have to define and design strict IAM user groups and policies, manage an umbrella of AWS accounts using AWS Organizations, and if necessary run your workloads on dedicated physical infrastructure via AWS Dedicated Hosts or AWS GovCloud. GCP, Azure, and other public clouds have their analogs to help you manage resources by application and organization. As for OpenStack environments – you can use Congress’s declarative language to describe what your resources should be, or limit who can access Horizon.
But here’s the tricky part: over 70% of enterprises already have multi-cloud environments while another 40% are planning to adopt a hybrid cloud strategy. So while we can go all in on one cloud and set up all of our architecting, replicating that same system of RBAC across clouds and resources is unsustainable. When I want to enforce standardization at scale, or make changes that take effect across an entire organization or group, I’d have to do it project by project, cloud by cloud. Bundling compliance requirements into each application might work for small organizations, but it gets messy at scale.
So how can we enforce compliance across our business units and applications and make it easy to change the rules of that enforcement?
Here’s how we solve those problems with Scalr’s Hierarchical Policy Enforcement and Policy Groups.
Here’s the hierarchy of Scalr:
Scalr’s hierarchical paradigm allows for top-down policy enforcement. You set your policies at one level, say a business unit, and all the applications and teams within that business unit can obtain those security requirements. If you need to specify by team or by application, you can do that as well. We integrate with AD and any other LDAP or SAML based identity system, making it easy to replicate your company’s existing organizational structure.
By mirroring your organizational structure, users keep the permissions that they already have. Think of your hybrid cloud infrastructure like a sprawling kingdom, with your security and compliance standards as the walls around it. To protect that kingdom, it’s easier to defend a single gate than a hundred. When enterprises have a many-to-many relationship with their clouds and datacenters, the attack surface grows significantly, a single enforcement point minimizes that attack surface.
So what are these policies or permissions that we can set on our users and resources?
Well, Policies in Scalr are just like policies in AWS or GCP or Azure – they define what actions users can do on cloud resources. Some examples are mandatory firewall configuration, remote authentication (e.g. LDAP) configuration, running scripts on production servers, or even automating the shutdown of testing environments after a few days.
You can set Policies at the Corporate scope so that the effects of those policies are propagated down through the entire organization. Set policies at the Account scope and they’ll affect everything inside the Account. Accounts usually represent business units (this could be a collection of teams and the resources), but they don’t have to.
In the screenshot below, I’m at the Account scope inside the Scalr UI. On my left I can see the Environments within that Account. In the main section I can see the policies I have attached to the Environment, along with the clouds being used, and the level of control that teams have. An Environment would be the collection of resources for a particular web application. There can be a Production Environment, a Dev Environment, Testing, Staging, and so on.
As an example, Developers can have free reign in a Testing Environment, but only admins and DevOps can make changes in my Production Environments. You can also set policies on the individual applications and the components of those applications within the Production Environment. For example, you may want everyone to see what security groups or Production servers run, but only admins can see what SSH keys are available. Or, to simplify what users see, state that they can only see the applications and resources that their team has access to.
The important thing to mention is that your cloud providers are not tied to a specific Account or Environment – your resources live where they matter. If your development servers are in AWS for rapid experimentation but your production servers are on OpenStack inside your data center, you can visualize and manage everything from one UI. Like we see above, you can set cloud-specific policies, which lets you get granular without jumping into each cloud console.
By bringing all of your resources into one pane of glass, the admins of an organization have far more visibility and control over what the users see and interact with. Here I can get a detailed look on the cloud credentials being used within each Account on each Environment, and who’s using what.
Here is how to handle teams that have access to these environments. Like your individual cloud providers you can set up teams and user groups, but with Scalr you can do it across clouds and at scale.
Here are the teams that are within this Account. I can see who the users are, what Environments they have access to, and create Access Control Lists (ACLs) that define their permissions at the Account level.
I can enable access on specific applications, cloud services inside cloud providers or even access to third party tools like Datadog or Chef.
Here’s an example of an ACL, which dictates everything that a user can see, gain read/write access to, and control. ACLs can be assigned to individual users, teams, or assigned to entire business units of users.
Using ACLs, here are some examples of what you can do with Scalr to create a secure cloud environment:
Set guardrails on instance sizes, security groups based on the user’s permissions and environment, SSH keys, auto-tagging on servers
Set a block on members of the First Week Developers team may only provision pre-built applications stacks from the Service Catalog, and may not build their own stacks
Members of the DBA Contractors team may view the security groups that are enforced on their infrastructure but may not modify them or create new ones
So what does this experience look like to the end user? Well, based on their permissions, they will have completely different experiences. More powerful users can have more access to different parts of Scalr (either through the UI or API), while developers that need simple solutions will see something like the Service Catalog.
Here’s what that looks like below:
For our simple users, we give them a simple interface so that there’s no gaps in the system. As an end user I can pick from this list of applications, and through policies that my admin set up earlier, I have a pre-selected menu of options I can configure for servers/cloud services that I deploy.
Here’s what that looks like for a LAMP stack application that we’re deploying. I can change the location of the application, the individual instance sizes, and the security group. If I had more flexibility, I could change the OS, the cloud, and whether or not this app’s instances are onboarded as Chef (or Puppet & Ansible) nodes.
Thanks for reading! This wasn’t a deep dive on how Scalr’s environments and policies work, but rather to show that using a single UI/API backed by a powerful orchestration and automation engine to handle all of your resources and user management can make your life to maintain compliance and security much easier.
If you have any questions or feedback, feel free to contact me at firstname.lastname@example.org.
See you for the next one.