In Fujitsu K5’s IaaS Platform there are many different ways of implementing a technology shared services architecture depending on your requirements.

[Update: 09/03/2017] : Before we continue however, let me quickly explain what I mean by the following two terms – Control Plane & Data Plane in the context of OpenStack and Fujitsu’s K5 IaaS platform. Let’s imagine that you’ve been asked to build a new Exchange service for a business on K5. This service will require the following infrastructure components, a network, router, firewall and a server to host the application.

Control Plane, used by K5 Infrastructure Administrators: In order to build this infrastructure you will need access to K5’s control plane services – the API endpoints that can talk to the Keystone, Neutron and Nova services. There is no need for regular users of the final Exchange service to access this control plane.

Data Plane, used by the end users of the service: Once the infrastructure has been built the Exchange administrator and end users will access the new server/services over the data plane – effectively they will talk to the new server directly through it’s virtualised interface.

K5 Shared Services Model – Without Control Plane User Isolation

The simplest design would be to put all of your instances into a single project and use security groups, and optionally multiple subnets, to provide data plane isolation or more correctly termed traffic segmentation. Obviously you can still also use the standard Operating System authentication mechanisms to control access to the virtual instances themselves.

Security Groups

One of the key components to the above solution is Security Groups. A security group in OpenStack is a mechanism for controlling all ingress and egress traffic flows on an interface (port) by interface (port) basis. A security group can contain multiple rules each defining the IP address range, Protocols and Direction of network traffic permitted. In a shared service model where server A and server B are to be isolated but both can talk to a third server C – security groups provide this isolation. Multiple security groups can also be attached to a single interface to build up the ruleset.

However, the drawback of this model is that the control plane project administrator has access to all the resources.

K5 Shared Services Model – With both Data Plane & Control Plane User Isolation

If you would like to ensure isolation at both the control plane and the data plane layers for your resources then this can be achieved by using the above architecture combined with role based access control, multiple projects and another of Fujitsu K5’s capabilities Inter-Project Routing.

Role Based Access Control (RBAC)

The Fujitsu K5 platform leverages OpenStack’s Keystone project to provide Role Based Access Control for users within a Contract (or Domain in native OpenStack terms). You can have control plane administrators defined on a project by project basis. This gives you the capability to spread your resources (virtual machines, networks, etc.) across multiple Projects and define which users have administrative access to these resources in the control plane.

Inter-Project Routing

The clue is in the title here, this feature of K5 allows you to route between networks in different projects within the same Contract.

Combining all these K5 capabilities lets us provide K5 Domain Administrators with the ability to control isolation of resources at both the control plane layer and the data plane layer.

For example, with the following model we can define a user that can administrate the IaaS resources in Project A and a different user that can administrate resources in Project B. Neither of these administrators require access directly to the resources in each other’s Projects or the Shared Services Project. However they will both be able to route to the services that are available in the Shared Services Project provided that the correct Security Group Rules have been applied.

The two models above are contained within a single K5 availability zone but these models can also be easily spread across the two availability zones with the use of another K5 component called a Network Connector.

K5 Network Connector

The Network Connector has two fundamental use cases –

• Route network traffic from external customer networks directly into a K5 project.
• Route network traffic between networks in different Availability Zones within the same project.

This connector avoids the need for customer network traffic to traverse the internet connection when traversing Availability Zones.

The following LAMP Stack example illustrates the use of a Network Connector with two Availability zones.

Happy Stacking!