The STRATEGIC Service Store is a multi-cloud proposition. The ability to manage and deploy applications to a public cloud infrastructure at the same time as to a customer’s Private or managed infrastructure was considered a requirement. The Service Store enables this by accepting a credentials from customer for a particular target cloud and then using its cloud connection SDK to communicate with the cloud infrastructures. The method is the same for all cloud infrastructures be it private (Openstack, Cloudstack) or public (AWS, Azure, BT Cloud, etc.).

Many Public cloud infrastructures have the necessary APIs exposed with sufficient security, such that a customer would generate an access key/password. This process of access generation is supported by an effective management policy that supports the management of its lifecycle. The customer’s responsibility, hence, is to ensure an approved and usable access key/password is available to the Service Store to communicate with the respective infrastructure.

In comparison, the private infrastructures are either based on Openstack or Cloudstack, that are primarily intended for data centre management, and lack the public API exposure management systems. In STRATEGIC, the solution was to  adopt a heightened security policy with restricted access control list (ACL) adhering to the security policies of the customer to whom the infrastructure belonged to. There were three types of access that were recommended in combination or on their own; there were given as options to choose from:

  1. STRATEGIC Service Store IP address to be white listed by the Infrastructure provider in order to allow IP restricted access to the infrastructure APIs.
  2. Creation of a site-to-site VPN between the Service Store provider and the infrastructure provider, with an ACL such that only a predefined set of Service Store servers are allowed to communicate with infrastructure APIs.
  3. Creation of a IPsec VPN server by the infrastructure provider, to which the Service Store provider creates a persistent VPN connection via a proxy server hosted by themselves to gain access to the infrastructure APIs.

A few things to be considered while adopting the above solutions are to ensure a secure communication channel to share pre-defined VPN keys and to ensure the API key management policies by the infrastructure provider are made aware to the customer such that they can update the Service Store with newer keys whenever necessary. Finally, the passwords and keys needs to be of sufficient strength and rotated sufficiently enough that advanced persistent threats can be detected or averted on a periodic manner.