Difference between revisions of "Blueprint-VPC"
(Openstack VPC Blueprint proposal) |
|||
Line 9: | Line 9: | ||
: 1 - The administrator of a domain can create a VPC composed of network resources. A generic VPC can look like: | : 1 - The administrator of a domain can create a VPC composed of network resources. A generic VPC can look like: | ||
− | + | [[File:Vpc-topo.jpg||VPC Topo]] | |
: Within the VPC, the administrator can : | : Within the VPC, the administrator can : |
Revision as of 23:58, 13 February 2014
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.
Contents
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
- 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 or definition of "share network" 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 [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.
[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