Protecting Your Cloud Deployments with Enterprise-Class RBAC
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy Pavan Pant
We recently talked about CloudSwitch’s security model while highlighting our integration with Active Directory. Our architecture addresses three areas of protection which we believe are required to make the cloud secure for enterprises – security within the data center, between the data center and the cloud, and within the cloud itself. Given that this is an area of paramount importance for enterprises I thought it would be useful to continue with the theme of security by discussing our role-based access control (RBAC) model. CloudSwitch’s RBAC capability is directly related to protecting resources in your data center from unauthorized access, while also controlling the privileges users have over cloud resources.
Years of experience in enterprise software development have taught us that retro-fitting an access control model is not a viable option – it’s like closing the barn door after the horse has bolted. Our solution was built from the ground up with an RBAC mechanism in place. We developed a granular RBAC model which allows administrators to delegate permissions across users and groups using roles and access control lists (ACLs) defined by a CloudSwitch administrator.
This gives customers the ability to group users with similar job functions into roles, and to give them authorizations to perform actions on objects in CloudSwitch. Our objects are entities such as folders, virtual machines, cloud accounts, etc. Using our RBAC capabilities allows customers to create a least-privileged access control model by only providing users with access that is absolutely essential for cloud operations. Every object and action in our system can be assigned to an ACL so that an administrator can enforce policies for cloud usage, cloud control, and local resource control. This approach allows customers to select roles in which users can operate, and the capabilities of each role are based on those users’ expected responsibilities. For example, a developer role might have permissions to create, clone, start, stop, and delete servers, whereas an operator role might only have start and stop permission.
Another important point here is that administrators can grant or revoke privileges on a CloudSwitch object independent of what the role does. As an example, you may have a set of IT administrators with privileges in CloudSwitch to start, stop, and delete servers that are running in the cloud. However, there could be a specific subset of production servers that you may not want even the IT administrators to control. With our RBAC model you can grant users permissions across the whole system with the ability to restrict access for specific servers.
These controls take on even greater significance as customers move production workloads to the cloud. With that in mind I thought it would be useful to walk through some of the RBAC use cases we have heard about from our customers, and how CloudSwitch can be configured to meet those use cases.
RBAC Use Cases
Use Case 1: Creating Sandboxes in the Cloud for Developers and QA
One of our large customers in the pharmaceutical space was running into a problem where their research scientists were increasingly faced with delays in gaining access to computing resources primarily due to a large and growing IT organization. They wanted to use the public cloud for their computing needs as an alternative to using internal IT resources.
Their primary objective was to deliver a streamlined solution to their developers which would allow them to clone read-only gold images created by administrators. The process needed to be as simple as possible with the appropriate security controls in place to prevent developers from modifying the images shared with them by administrators.
With CloudSwitch, this customer’s administrators were able to easily upload their gold image to the cloud, provision a server template in the cloud using the gold image and place it in a folder structure within CloudSwitch that only developers could access. Once that step was complete, the customer used our RBAC model to ensure that developers had permissions to clone the server template made available by the administrators and permissions to perform server lifecycle actions on the cloned server (start, stop, delete, power off, add NICs, add disks).
The end result was that developers could easily login to CloudSwitch’s user interface, clone the administrator template that was made available to them, start that cloned server in the cloud and shut it down when their work was complete. This was a much quicker and cost-efficient way to get access to compute resources in the cloud, especially when compared to the customer’s previous approach of waiting for resources from their IT department. It also ensured that the developers had just the right amount of privileges to perform their daily activities in the cloud.
Use Case 2: Network Administrator Privileges
Our customers have also frequently asked us about separating out permissions such that only specific users have the ability to modify network settings for cloud networks. Customers wanted each department to control their own network mappings without allowing other users or groups to modify the networking configuration.
To solve this problem with CloudSwitch you would simply create a role (e.g., a Network Admin role) and define an ACL where only users in that role would have the ability to configure the network and NIC configuration for servers in the cloud, or even networking configurations for CloudSwitch components. You could even go a step further by creating a “Network Administrator Subnet 1” role for servers on a specific subnet in the cloud, and a “CloudSwitch Network Admin” role for users who only have permissions to manage networking configurations for CloudSwitch components such as the CloudSwitch Appliance which resides in your data center or private cloud.
Other Common Use Cases
Other customer scenarios involve using RBAC to define and limit which import sources can be moved to the cloud, and which target clouds can be used. CloudSwitch allows customers to migrate virtual machines from VMware or Xen to the public cloud without making any changes to the virtual machine (e.g., no changes to the kernel, OS, IP address, MAC address, storage controllers, subnet information, etc.). As part of this process, you can define import sources from VMware or Xen in the user interface, and specify which roles get access to those resources. You can create multiple import sources in CloudSwitch for different groups within the organization while ensuring that the appropriate people or groups (e.g., Development, Quality Assurance) have the right amount of access to these import sources. We have also had cases where customers want to restrict which cloud regions (or cloud providers) certain groups have access to. For example, one of our customers wanted most of their users to deploy in Amazon’s US-East region since it is cheaper than US-West. However, there was a group on the west coast that really benefited from the geographic proximity of using US-West. CloudSwitch’s RBAC model allowed this customer to grant that one group access to the more expensive resources in US-West while the rest of the organization was restricted to using resources in US-East.
These are the types of granular access control capabilities that a growing number of customers have requested, especially as they move production workloads to the cloud. It has been great to see large enterprises across verticals using our RBAC capabilities to secure their cloud deployments, from the data center, to the cloud and within the cloud. CloudSwitch was designed with the hybrid cloud in mind and our core value proposition lies in the ability to securely transport your virtual infrastructure to the cloud provider of your choice without requiring any modifications. A large part of that vision hinges on giving enterprises the ability to control the type of access people have both in your data center and in the cloud. We’ve built a solution that gives customers the ability to use their existing security policies and permissions in the cloud instead of creating new ones for their cloud deployments.
Reader Comments
There are no comments yet. Be the first to create one!
