Difference between revisions of "ProjectVpn"
| Line 12: | Line 12: | ||
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>. | 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 == | == User stories == | ||
== Assumptions == | == 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 == | == 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 == | == Implementation == | ||
| − | + | Cloudpipe needs to support: | |
| + | * automated creation of the vpn | ||
| + | * management of the vpn | ||
| + | * allocating and revoking certificates | ||
=== UI Changes === | === UI Changes === | ||
| − | + | The UI at this point is simply nova-manage commands, so no design changes are required. | |
=== Code Changes === | === 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 === | === 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 == | == Test/Demo Plan == | ||
| Line 51: | Line 60: | ||
== Unresolved issues == | == 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 == | == BoF agenda and discussion == | ||
Revision as of 16:24, 2 November 2010
- 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.
