security
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.
After Security, Network Bandwidth is the Next Cloud Bottleneck
By Ellen Rubin
Security concerns (real and imagined) have long dominated much of the cloud conversation and caused many companies to deliberate about getting started in the cloud. Slowly, the security issues are being addressed--through the adoption of corporate policies for cloud usage, maturing cloud provider offerings, and by technologies such as CloudSwitch which isolate and encrypt all cloud resources to meet the requirements of the CSO. But while the focus has been on cloud security, another potential bottleneck is on the horizon as companies start using the cloud in more substantial ways.
In our discussions with IT executives and their teams, we’ve been hearing about a new concern: the ability of corporate networks to handle cloud traffic. Network performance is a lurking issue that hasn’t yet received the attention it deserves. That’s understandable, since bandwidth is rarely a problem for companies exploring the cloud in a small way, where they may deploy a few experimental VMs in order to understand the process. But as they start expanding their cloud footprint and running production-oriented applications, data movement takes on a completely different scale. As enterprises start to move real workloads out to the cloud (or to straddle internal and external clouds), look for network performance to become top of mind.
IT professionals and developers often assume they have huge network capacity, and it’s probably ample for their current Internet usage or the small cloud projects they may have tried so far. But what will happen, for example, when you have dozens of developers all trying to use cloud resources? Or if you put high-transaction processes in the cloud that need to “talk back” to your data center? What if you are trying to move a lot of video or graphics between your business users and the cloud? Network usage is about to get much more demanding, and the traffic will need to flow without bottlenecks (or saturating the network) for an organization’s cloud strategy to work.
Thus potential cloud users will have to do some back-of-the-envelope analysis of the maximum bandwidth they might need and how much additional traffic the network can handle. While the data center (or internal network) is running at speeds of 1Gb and even 10Gb, the connection to the Internet is lagging behind. Today, a “good” Internet connection is considered to be in the 100Mbps range. Some companies have more, and many have less than this capability, so when extending services to the cloud, you have to consider what impact this lower speed could have, and how to deal with it.
This is actually a two-part problem. You have to consider initial data movement: how long will it take to move a terabyte of data over the Internet and into the cloud? What impact will that have on current users and your business? You also have to look at ongoing updating of that data: how much traffic will be flowing back and forth, and what will that mean for your steady state? Will you have to buy more bandwidth for the cloud to be viable? Obviously, any major new capex requirements would be a challenge for cloud adoption.
Fortunately, technologies are emerging that can help optimize your current network and avoid an expensive upgrade. For example, CloudSwitch has a public IP address capability that provides direct access to cloud resources without having to go through the enterprise data center, avoiding what could otherwise be a huge bottleneck. Rather than relying on the Internet connection to the data center, cloud deployments can take advantage of the aggregate bandwidth of end users. This CloudSwitch feature also allows enterprise firewalls and load balancing capabilities to run in the cloud so traffic can flow smoothly and securely. In addition, companies like Citrix, F5, Riverbed, and Cisco are developing software versions of their WAN optimization technologies that can be deployed in the cloud. Their innovations in compression, de-duplication, and other techniques will enable much more efficient data movement so you can make better use of the network you already have.
If you’re the head of IT or Application Development looking ahead to 2011, you probably have some great cloud pilots under your belt, and you’re evaluating moving into the cloud in production mode. Just remember that bandwidth is something you’ll need to think about and prepare for.
CloudSwitch has been thinking about these issues, and together with our partners we’re working on solutions to ensure optimum bandwidth for the cloud. Emerging technologies will allow you to meet the bandwidth demands required by production applications, so you can scale out your cloud footprints without building out your corporate network, leveraging the investments you’ve already made.
