News
BackPrivate Networks Across Project Boundaries
At cloudscale you can group cloud resources that belong together in projects (e.g. to separate your test setup from your prod setup) and thus also allocate graduated access rights to those involved. You can use private networks to connect virtual servers if you do not want individual ones (e.g. a DB backend) to be accessible from the internet. So why not combine these two concepts? Network sharing enables you to share private networks with other projects if required, also across account and organization boundaries.
Separate projects, joint network
You can use private networks to "wire up" virtual servers internally in one cloud location, e.g. a web server that accepts requests from clients with the associated database backend. Where individual servers do not need to be accessible from the internet at all, this means that you can minimize the target area for attacks. You can now also connect your servers and load balancers using a private network if they are not in the same project.
Projects not only provide a clear overview of and bring order to your cloud resources. If different teams within your organization are responsible for the maintenance of, for example, web workers and DB clusters, you can determine their access rights in the control panel for each project separately. With separate projects and a shared private network, you can then clearly map the responsibilities and isolate the databases from the internet, while ensuring that they remain accessible from the web workers.
A further example of a separation of this kind could be, for instance, when management of your firewall has been outsourced to an external service provider (and this partner organization has been granted access rights to the firewall project in the control panel). The filtered traffic can then travel through the private network to the servers in your other projects. Or you may have a centralized log server that you run in a separate project (key word: segregation of duties). Finally, you can also use this to limit the scope of an API token that you have stored in a tool for automation purposes.
Make the most of shared networks
If two projects are to share a private network, first determine which project should be the owner of the network. Details such as the name or MTU of the network can only be changed from within this project at a later stage. For the actual sharing (or to change the circle of participating projects later), notify our support team. You will find the link for this in the control panel under "Network > Sharing".
The properties of the private network are visible to all participating projects, in particular e.g. the name of the network so that it can be identified without doubt when connecting a server. The MAC addresses and – provided they are managed via DHCP – the IP addresses of all devices in this network are also visible under "Network > Ports". While these technical details are accessible to everyone in the network anyway (e.g. by means of ARP requests), they also help you to avoid collisions and any subsequent errors. The names of servers and load balancers in other projects, however, are not visible; devices of this kind are simply displayed as "Other Device".
With regard to IP addresses, you can use any IPs in your private network, which allows you to consider existing address patterns already used by a participating project. You will find further information on the configuration of the desired subnet and other DHCP features in our article on Managed DHCP.
Shared private networks allow you to guarantee internal data flow between the correct systems without all of them having to be in the same project (and thus managed by the same people). This ensures that you can structure access rights more precisely and centralize services that are used by several projects – both within your own organization and with partner organizations.
Network? Go!
Your cloudscale team