Blueprint-VPC

The goal of this blueprint is to add support for VPC in Openstack. A VPC is defined as an entity defining resources access boundaries with the goal of providing a logically isolated infrastructure 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.

Relationship with other blueprint

Hierarchical Multitenancy [1] tries to define a hierarchical model for resource ownership and containment

AWS VPC API support [2]

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.

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

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

Hierarchical Container

1. 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.
2. Domain admin would create a VPC as a domain level object.
3. Domain admin can add role of VPC admin to user and delegate VPC management to this VPC admin
4. in Neutron : The shared network semantic has to be updated to allow the scoping of shared networks to a VPC .
5. in Glance : Sharing of image has to be extended enable the sharing across projects within the VPC.
6. in Cinder : same as glance.
7. allow the specification of metadata associated with the VPC to capture for example the DNS Zone associated with the VPC.

Policy Based

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

---

[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