Difference between revisions of "ProjectVpn"

Revision as of 23:30, 17 February 2013

• Launchpad Entry: NovaSpec:project-vpn
• Created: 11/01/10
• Contributors: Vish Ishaya

Summary

In vlan networking mode, users need a way to access the private network for their instances. This was supported by per-project vpns (code named cloudpipe), but unfortunately has not been maintained properly. Additionally there are a few security issues with the old implementation.

Release Note

Nova supports per-project vpns in vlan network mode, code named cloudpipes. These allows a user unrestricted access to the instances inside his or her project. The vpn can be accessed through port forwarding from the network host, or by automatically giving the vpn a public ip. Instructions for setting up cloudpipes can be found <here>.

Rationale

Nova supports a secure network configuration in which each project is given its own vlan and private ip range. This is a fairly secure way to isolate projects from one another. Because of this isolation, we can give users free reign within a project to access other machines on the network, instead of carefully setting up firewall rules and making all of their instances available on the public internet. In order for this scheme to work effectively, users need a means to access the private network for their project. Cloudpipe (a per-project vpn instance) offers this means.

User stories

Assumptions

Vlan isolation is easier to manage on a host level than using custom ebtables and iptables rules. It does require that the switch connecting the networks supports host-managed vlan tagging. If such a host is not available, then another network mode is required.

Design

Cloudpipe is a customized instance that runs on behalf of the user as a vpn. While it would be possible for a user to set up their own vpn, some control over networking is required, so it makes sense for the vpn to be managed (at least partially) by nova itself.

Implementation

Cloudpipe needs to support:

• automated creation of the vpn
• management of the vpn
• allocating and revoking certificates

UI Changes

The UI at this point is simply nova-manage commands, so no design changes are required.

Code Changes

An older (unworking) version of cloudpipe is already in the codebase. This needs to be updated to include new features. These include:

• integration with security groups
• use the new database
• revokation of certificates
• better management commands
• remove cloudpipe from api for signing via http (this is extremely insecure)

Migration

A new table will be added to the database representing certificates. Due to changes in the structure of CA's and certs, new credentials will need to be generated and sent out to users. If the cloudpipe functionality is not required, a flag is provided to disable the new cert structure and keep existing functionality.

Doc Changes

Docs will need to be updated explaining how to use cloudpipe properly. They must include the management commands as well as how to create cloudpipe images.

Test/Demo Plan

This need not be added or completed until the specification is nearing beta.

Unresolved issues

Project cloudpipes have an impact on quotas. The current implementation uses full instances to run openvpn, but this can be replaced with very tiny instances running some kind of busybox linux like OpenWRT. It also may be useful to mark vpn instances in some way in order to: a) hide them from the user and/or b) change the calculations for the scheduler (it may make sense to only count a tiny cloudpipe as a 1/10th of a core when calculating the load of a server for example);

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.