Security is one of the key advantages of on-premises cloud infrastructure over public clouds, but only if it’s properly implemented. There are several layers of security to be considered in this environment. In this article, we’ll look at six key attributes of on-premises cloud security.

A private cloud platform should provide a variety of tools and features to protect user accounts and resources from unauthorized use. This includes using credentials for access control, HTTPS endpoints for encrypted data transmission, several logical administrative/user accounts and associated authentication and authorization, user activity logging for security monitoring, etc. Users and credentials are stored and encrypted on premises and are never transferred to the cloud. Authentication and authorization is also done on premises.

Secure registration

A secure registration process is used to validate, verify, and register a customer and the servers.

When the cloud is first installed, a cloud vendor representative sets up IP addresses on the hosts via a SSH terminal session to the server console.

Access controls

The primary roles are cloud administrator, business unit administrator, project administrator, and project member. All four groups use server-side authentication to gain access to the system. Users should be able to connect the cloud to any Active Directory (AD) or Lightweight Directory Access Protocol LDAP directory and import the user and group information for authentication. Each admin/user group has different levels of access and privileges.

Cloud administrator role – One or more cloud administrator roles and associated credentials are created at the time of initial cloud creation and deployment. The administrator should provide valid email address(es) and initial password(s) for the authorized customer representative(s) to access the cloud at this point. Authorized cloud administrators have full access, visibility, and privileges to all the BU/project accounts and global settings. However, they do not have login access to the physical server or networks. Here is what cloud administrator(s) can view and what actions they can perform:

  • View the infrastructure dashboard that provides a high-level summary of the health of the entire cloud environment, capacity usage against quota, inventory view, as well as CPU and storage utilization.
  • View detailed information at the region, AZ, hosts, network, and storage, including events and health of the systems.
  • Create business units, associated quotas, and business unit administrator accounts including usernames and passwords for BU admins.
  • Create projects, users and their associated usernames and passwords, and assign users to projects.
  • Configure global settings such as placement policies, project templates, VM flavors, notifications, etc.
Figure 1: Cloud administrator and user roles
Figure 1: Cloud administrator and user roles – ZeroStack

Business Unit administrator role – Business Unit administrators are responsible for their individual business units and have the ability to create projects, project admins/members, and resources within the quota that was assigned to their BU. Here are the activities that a BU admin can perform:

  • Create their own projects.
  • Create new project administrators and their associated usernames and passwords.
  • Create new project members and add them to specific projects.

The BU admin is only able to edit, view, and monitor resource utilization (VMs, storage, network) and consumption information against a quota within their own business unit. They don’t have privileges to view any global infrastructure information or other BU information.

BU admins can change their own password, and they can reset passwords for other project administrators and members belonging to their BU.

All credentials can be locally created or can be created from the existing AD/LDAP profiles. Each BU admin have a choice of selecting an AD/LDAP or local users for authentication. Administrators are responsible for managing BU and Project member privileges and for enforcing any strong password policies.

Project admin role – Project admins have the ability to create, for their individual projects, VMs, storage, and network resources within the quota assigned to them by the business unit administrator. They can view utilization and consumption of resources against the quota within their project. The project admin can selectively share some resources shared globally, in which case other BUs and projects can view these resources. By default, project admins do not have privileges to view other projects or business units.

Project member role – Project members have access to only those projects that have been assigned to them. They can create resources like VMs or images within the assigned quota of the project. They cannot create any new resources and do not have access to other projects or BUs.

Authentication

The credentials for cloud administrator, BU administrator and the project admins and users as well as external accounts such as VMware, external storage, and Active Directory are stored on the on-premises cloud. All account credentials are stored securely using one-way encryption in the internal cloud authentication database on premises. In the case where customers use Active Directory, the authentication can be delegated to it so that credentials are stored in the Active Directory itself.

Once a user is authenticated, a temporary session key is obtained from the on-premises cloud authentication service and is used for user actions and commands performed in that session. When the key expires or the user logs out, the user will have to login again with the credentials.

Access to cloud APIs uses the same mechanism as the actual login. The first API command uses the credentials to login and accesses a session key that is used by subsequent API commands.

Key pairs

The private cloud should enforce the use of public/private key pairs to properly protect access to a VM. Public/private key pairs work by keeping the public key on the server, and the private key on the local workstation. In some cases, the cloud platform injects a public SSH key into an instance on launch, so that it’s ready for users to access using the private key. If you then set up SSH to deny password authentication and instead require the key, you give the cloud instance a much stronger layer of security. The cloud will verify that the two keys match before establishing a secure connection. Ideally, the keys should be 1024-bit SSH-2 RSA keys.

On-premises security

There are several tools and techniques to ensure that the on-premises cloud infrastructure and data are secure and safe.

The cloud servers physically reside on-premises in a customer location behind their own firewall – the servers on premises are not directly reachable from the cloud software. This means the cloud layer or any other cloud software cannot directly contact the on-premises servers. Additionally, the base OS running on each server is protected by a user ID and password.

Customer data stays on-premises – all of the customer-created compute instances, data volumes, networks, and object store data are stored on the on-premises hardware. In addition, image and application templates are also stored on-premises. Only cloud, business unit and project administrators with the appropriate credentials and roles will have access to the assets in the system. All the passwords and certificates are also stored on premises, where the authentication happens either locally on the cloud platform or via Active Directory or LDAP, if it is configured.

SaaS security – all communication between the cloud and the on- premises servers uses HTTPS to encrypt traffic. The cloud should establish only outbound connections. The following telemetry data is sent encrypted to the cloud over HTTPS (through a single port 443, which is already open for HTTPS Internet traffic) and stored in a database for management and operations:

  • Names and IP addresses of hosts and VMs
  • Names, types and sizes of storage volumes associated with VMs
  • Names of Projects and Business Units
  • Events generated by the system
  • Statistical data such as for physical and virtual resources - e.g., CPU utilization, memory utilization, storage IOPS metrics, etc.

No inbound connections are established and no new ports need to be opened on the firewall - this ensures an added level of security and reduces vulnerability to attacks. Events, stats and metadata about VMs, storage, and usage information are the only data that is transferred to the cloud for monitoring, analytics, planning and chargeback features.

Application security

There should be three levels of security for applications:

  • Per-VM firewall policy – Every VM comes up with no ports opened as the default.

Users can assign a security group (which is a collection of ports and protocols) to each VM to allow access only on specific ports. This is a distributed firewall that scales well with the number of servers and VMs. The firewall policy is implemented at the hypervisor level and works in conjunction with any perimeter firewall rules.

  • Runs behind a perimeter firewall – Customers can run the cloud platform behind their standard perimeter firewall, so developers don’t have to worry about making sure that the VMs are not running any binaries that may have potential exploits or weaknesses. Typically, developers are not well-versed with security and operations. On a public cloud, everyone who is deploying a VM has to be careful about which ports are open and which applications are running. They also have to be very careful about installing any new applications. This can slow down the innovation process and application delivery agility. This is one of the key advantages of private cloud over any public cloud.
  • Users can create private networks that are completely isolated from each other – Each application or set of VMs can be deployed on a private network. One can choose any subnet while creating these networks and does not have to wait for a network administrator to provide an IP subnet range to use. This enables faster self-service and isolation. With isolated networks, even if an application or VM is compromised, the attacker can access VMs only within that private network.

With these three different levels of application security, users get a completely secure cloud as compared to public clouds or standard virtualized environments. In most private clouds, customers have to use physical segmentation using VLANs – a process that doesn’t scale well and slows down the application provisioning.

As we have seen, a private cloud can be made extremely secure through the use of access controls, secure registration, authentication, on-premises security, and access security. Leveraging these security techniques allows administrators to gain the maximum benefit of an on-premises cloud.

Kamesh Pemmaraju leads product management, product marketing, and technology partnerships at ZeroStack