• QuantumCloudpipe

Cloudpipe in Quantum

Summary:

Cloudpipe support in Quantum will let external users create a secure tunnel into a tenant network.

Note:

CloudPipe is special use case for generalized L3 services. However, as a first step, we refactor the current cloudpipe effort into Quantum and obtain Nova parity. The design goal is to have a flexible mechanism for inserting this service.

Use Cases:

1. Allow an external user to VPN into a network and get an IP address an internal (to the network she VPNs into) IP address for any network.

2. Allow a TenantAdmin to create private network topologies and create VPN tunnels from the external network into these networks (which could be edges of a private topology).

3. Allow a TenantUser to determine the tunnel details of every virtual network/edge (of the topology).

Target “Quantum:Admin” workflow:

1. Allow CloudPipe/VPN access to this user.

Target “Quantum:TenantUser” workflow:

1. Specify a cloudpipe image (it could be per network or a fixed cloudpipe image for the entire tenant)
2. Retrieve credentials for the cloudpipe.
3. Enable cloudpipe for a given network.

Implementation:

Changes to Quantum:

• API changes to Quantum would include adding attributes to a network upon creation for the cloudpipe. An alternative is to specify it separately (not during creation).

Changes to Nova

• During creation of a VM, pass the handle to a network. This is required because the VM creation process would include a script injection with the parameters that are specific to the network, before the network is even attached by Quantum.
• Hence we need API changes for the above.

Design Notes:

How Cloudpipe works today: The details are here... however a short list of steps are as follows (in the context of the VLAN manager):

• For every project, the network manager will assign a single VLAN, and a single subnet

• When a cloudpipe instance is run (e.g. $nova-manage vpn run <project_id> <user_id>), it does a bunch of things including, generating a zip file with a boot script thats executed during bootup of the cloudpipe VM, setting up security groups (to allow ICMP and UDP port 1194 (IANA's port for VPN). Code for this is here.

• The bootscript needs params like IP address config params and other stuff as outlined in this script.

• Once this VM boots, it is placed in the correct VLAN, and given an IP address of x.y.z.2 (reserved for the instance). The bootscript is obtained from the metadata server, unzipped and executed. This has the needed params.

In order for the cloudpipe to work with Quantum, here are some of the changes that are needed:

• Each project can have multiple networks eventually. Thus, potentially we can have a separate cloudpipe for a given network.
• Hence, the cloudpipe instance needs to be brought up on a specified network programmatically.
• This implies we need to change the nova api to have a network handle when instantiating the cloudpipe instance.
• Thus one way would be to pass the network handle into pipelib.py so that when the VPN instance is launched, parameters that are fed into the bootscript template are obtained from the network handle (rather than a fixed network per project).
• Questions:
  • Should we have a configurable IP address for the cloudpipe VM (specified via API)?
  • Should we have different parameters for each cloudpipe instance?
  • Should we assume only one cloudepipe instance per network?