The Cisco-VMware-NetApp (CVN) was discussed on the Virtualization Security Podcast as it pertains to Secure Multi-Tenancy (SMT). This is a major concern that was also discussed at RSA Conference 2010 within the Cloud Security Alliance Summit. The question still remains how to achieve this goal however. CVN is a very good start, but as we discussed on the podcast is missing some key elements listed below:
- How to define and identify of the various administrator roles: Application Admins, IaaS Administrators, and Cloud Administrations.
- How to expose Roles and Responsibilities to these administrators
- How to identify these administrators
- How to authenticate and authorize these administrators
When we look at the components of CVN there are security implications at each level:
- NetApp vFiler and its configuration and presentation of LUNs over different IP address ranges
- Cisco Nexus 1000v configuration to additionally protect the environment.
- VMware vCenter Roles and Permissions and its limited functionality.
The NetApp vFiler is does provide storage segregation for the tenants within a cloud or virtual environment by providing virtual filers with their own IP address and virtual controllers within the physical filer. Granted, deep down we are probably trusting the physical filer kernel network stack much like we are within any vSwitch (Rethinking vNetwork Security), we all agreed within the podcast that the filer is not the important aspect. While not built into the Filer, encryption of data at rest can be achieved using Decru and other storage devices as we have discussed before on the Virtualization Security podcast.
We did not spend much time discussing Cisco’s involvement as we have delved into that quite a bit but their involvement is based on the Cisco USC and Nexus 1000v. Yet, the majority of the conversation was around management.There are three classes of administrators involved:
- Server Admins/Application Admins who work within a virtual machine. These keep the apps running and use directory services from the tenant and are usually Domain Admins.
- Tenant IaaS Admins who are Tenant administrators that require to see some level of the underlying layer to ‘see’ more of what is going on: Power on and off hosts, create VMs, vSwitches, etc.
- Super or Cloud Admins who can see and control everything.
The issue with these roles of administrators is that the Tenant IaaS admins need access to the underlying layers and the Cloud Admins can ‘see’ everything within the Tenant. So SMT, requires several possible rethinks.
- How to prevent cloud admins from accessing confidential information, perhaps encryption of the virtual disk, network, and memory is the answer.
- How to give access to Tenant IaaS Admins so that they can do their jobs, yet have compensating controls so if those Admins move to a different Tenant directory services are properly updated within the Tenant and perhaps the cloud environment.
VMware vCenter’s involvement had several major issues:
- Roles and Permissions within vCenter had to be properly configured to give segregation of data, but vCenter exposes so much functionality that one misconfiguration can give other tenants a view into the existing enviroment.
- Exposure of simple tasks as remote console from vCenter would be limited and most likely should not be allowed.
- Each Tenant IaaS Admin can see more ‘functionality’ then they are allowed via the vSphere client so will try things not considered.
There are many solutions to the problems discussed. The Tenant IaaS Admin is the trickiest by far, perhaps there needs to be vCloud/CVN weblets that allow them to do their tasks using delegate users within the virtual/cloud environment. However, the Cloud Admins still can access everything unless the Tenants encrypt their disks and network communications but this can add excessive over head which could end up costing the tenant even more $$s.
CVN is a good start for Secure Multi-Tenancy, but more work needs to be done on the management piece to fit the three roles defined.