NetApp’s SecureMulti-Tenant(SMT) architecture with CloudStack

Security in the cloud

Cloud is no longer a buzz word today. More and more enterprises are making cloud a reality, as cloud proves to be agile, scalable and cost effective. However, not all mission critical applications are on the cloud. One of the top reasons for this is the concern of security in the cloud.

To understand these security concerns, CloudSecurity Alliance(CSA) conducted survey to understand the current security issues with the cloud and suggest remedies for the same. The survey results reveal that Malicious hacking of credit card details, improper authentication mechanisms offered by the Cloud service APIs, shared resources (like CPU, memory etc ) are some of the cloud security concerns.
Remedy for Cloud Security

While the application and on the wire security have to be paid attention to, in this article, we shall focus on the shared infrastructure resource concern in the cloud and how it can be mapped to the business logic. Say a cloud based testing application can segregate multiple subscribes’ data, however when it is stored in the cloud, network to access the storage and the controllers to access the storage device are ideally shared. To ensure multi-tenancy and security across cloud subscribers at the infrastructure layer, even the underlying infrastructure should be multi-tenant. What this means is to compartmentalize the infrastructure resources for a subscriber.

Multi-tenancy provides the ability to segregate the sub-level infrastructure resource provisioning for different tenants. NetApp, VMware and Dell integration provides an architecture through which the compute, storage and network are partitioned and provisioned at a tenant level. Solutions like CloudStack provide the business logic and the management interface for managing these multi-tenant resources.

Muti-tenancy at the infrastructure layer

NetApp’s vFiler, VMWare’s vStorage and datastore along with Cisco Nexus switches and servers, provide the necessary compartmentalization of the compute, server and network. To stitch these three together, vFiler provides IPSpaces which associates a vFiler with a VLAN or an IP.

vFiler contains a routing table (IPSpaces) and the actual data store. The network interface/virtual network interface of the storage servers can be mapped into the IPSpaces. Given that a network interface can only be a part of a IPSpace at a time, a strict security enforced at the vFiler level.

Now that the storage are compartmentalized, automatic provisioning of a vFiler for a VM (for both vmdk & data) is done using the NetApp’s VSC plug-in for VMWare. At the network layer, Cisco Nexus provides the compartmentalization and redundancy of the network layer using the vPC and Nexus 7000v virtual switches.

The VMWare vShield provides the necessary zoning for the VMs & their NICs. This is done in conjunction with the Cisco Nexus 1000v to create virtual Networks (vNetwork). Nexus 1000v also maintains the network state during VM migrations and provides the necessary firewalling and monitoring.

For the configuration of the above mentioned architecture check : Deploying Secure Multi-Tenancy into Virtualized DataCenters.
Cloud Stack Solution

After achieving the multi-tenancy at the infrastructure layer, the business logic has to be capable of configuring and managing the multi-tenancy. Cloud.com’s CloudStack is inherently multi-tenant and helps to configure and manage tenancy at infrastructure layer.

The host/compute components are grouped as zones, pods and clusters, while the storage components can be either primary or secondary. Similarly network can be provisioned for public IP, guest or zone wide.

At the user management level, domains and accounts can be created. CloudStack architecture allows an account manager to utilize the Direct VLAN to allocate user level VLANs. Each user can be allocated a VLAN. These VLANs can be trunked in to the vFiler IP spaces to associate a vFiler with a particular user account.
How SMT and CloudStack can work together

In case of a non-vFiler based allocation, the user has to choose the VLAN that is available in the zone. The user has no control on where the vmdk file is created in the storage pool. The vmdk could be create on any of the primary storage available within the zone/POD.But, in case of Netapp & Cloudstack SMT architecture, the user can choose the public/private VLANs (storage network created using the cisco’s virtual network configurations) for the VMs and also the user can provision the VMs from storage available within the secure storage VLAN that was chosen.