Blueprint-VPC

The goal of this document is to provide an umbrella blueprint defining how to add support for VPC in Openstack.

A VPC is defined as an entity providing resources access boundaries with the goal of building a logically isolated infrastructure assigned to a tenant.

There are multiple options to implement this entity, either as a formal node in the openstack container hierarchy (domain, projects), or as a tag used to define access policies.

Hierarchical Multitenancy [1] defines a hierarchical model for resource ownership and containment. This blueprint can be used to implement the VPC concept by considering each VPC as a node in the hierarchy.
AWS VPC API support [2] aims at providing an EC2 VPC equivalent API on openstack. This blueprint uses a special project to group the VPC resources, however, it doesn't address the needed changes in scoping of different resource to implement a true isolated VPC.
Hierarchical Administrative Boundaries [5] defines a model similar to [1] and is focusing on defining administrative delegation.

Use cases

1 - The administrator of a domain can create a VPC composed of network resources. A generic VPC can look like:

Within the VPC, the administrator can :

1.1 - create a shared network. A shared network in the VPC is equivalent to a Neutron public network (it's a public network with a restricted scope).

1.2 - create a transit or external network that can be connected to a remote datacenter through, for MPLS or a VPN or to the internet.

1.3 - define specific flavors, images or other openstack resources restricted to be used within this VPC (e.g. DNS Zone, LB Resources, ...).

1.4 - define quota for resources available to a given VPC.

2 - The domain administrator can delegate the management of the VPC to a user or group of the domain

3 - A user of a domain, can create a project within a given VPC. Within this project, the user can

3.1. create a private network using the VPC external or shared network as the next hop. VMs can get a floating IP from the shared or external network

3.2 create a VM within a project attached to a shared network exposed by the VPC.

Resource Model

The above model is showing a relationship between VPC and Project assuming a containment relationship. However, as shown below, depending on the implementation, it could be a more loose relationship.

Implementation options

Project Based

create a VPC administrative project - this could be a project owned by a domain admin.
Create network objects in above mentioned project to build the VPC topology.
(optionally: see [3]) update project creation flow by allowing the scoping of project to a given VPC (tagging project with specific VPC)
update network selection (e.g. in Nova scheduler) or definition of "shared network" (in Neutron) to restrict to only tenant private networks or VPC shared networks

Hierarchical Container

Implement VPC as a container similar to a project that can be used to contain resources and projects. This could use the concepts defined in [1], as long as we can have more than admin and project as levels in the hierarchy.
Domain admin would create a VPC as a domain level object.
Domain admin can add role of VPC admin to user and delegate VPC management to this VPC admin
in Neutron : The shared network semantic has to be updated to allow the scoping of shared networks to a VPC .
in Glance : Sharing of image has to be extended enable the sharing across projects within the VPC.
in Cinder : same as glance.
allow the specification of metadata associated with the VPC to capture for example the DNS Zone associated with the VPC.

Policy Based

Similar to Amazon AWS IAM policy model [4]
Use the project as a container for VPC level resource
Construct a set of policies to implement isolation and sharing characteristics like [4].
In this model, the VPC is not really a first class object, but a group of policies.
Some open issues : specification of metadata at the VPC level, user experience.

Resulting Blueprints

The implementation of the VPC will require multiple blueprints in the various projects to cover the full functionality. After discussion, we will provide in this section the related blueprints.

[1] https://wiki.openstack.org/wiki/HierarchicalMultitenancy

[2] https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support

[3] if a project is not scoped to a VPC (tagged with the VPC id), the resource created within a project can use any of the Shared VPC Networks within the user scope (e.g. domain scope).

[4] http://docs.aws.amazon.com/IAM/latest/UserGuide/ExampleIAMPolicies.html

[5] https://blueprints.launchpad.net/keystone/+spec/hierarchical-administrative-boundary