In the openstack-installations there are usually two external networks. "ntnu-internal" provides NTNU-RFC1918 adresses, which are reachable from all of NTNU, but global access is only through VPN. "ntnu-global" provides globally reachable IP addresses, making your virtual machine available globally. The following table lists the IP prefixes used in the platform:

Using ntnu-global

Access to globally available addresses are given on request, if you have a legitimate use for it. Access is given on a per-project basis, and even after the access is given we encourage you to use ntnu-internal where global addresses is not strictly needed.

Security considerations

The global address-space is available globally, meaning any internet-connected system in the world can initiate contact with VM's having a global IP. The IPv4 address space is rather small, and are regularly scanned, and you should thus expect automatic scanning hitting your VM as soon as it gets a global IP. This means that you should be very careful about which services you expose from your VM to the global internet to avoid having your VM exploited. Even though we encourage to be careful about security in all your VM's, it is particulary important for VM's being globally reachable. For VM's having global addresses we recommend:

• Use security-groups to limit access to your services:
  • Administrative interfaces (SSH, Remote-Desktop, VNC etc.) should ONLY be allowed from known networks.
    • NTNU uses many address-ranges but allowing access from 129.241.0.0/16 and 10.0.0.0/8 should cover the majority. 
    • Check the addresses used at your systems if they are not covered by these ranges.
  • Access to services should only be given globally to the specific ports needed.
    • For web-applications this typically means TCP port 80 (HTTP) and 443 (HTTPS).
  • You should not give global access to services intended for internal use in your applications, like databases, message-queues, cache-layers etc.
• Keep your services updated
  • It is particularly important to keep services available to the global internet updated, to avoid having knows security bugs that can be exploited.
  • We recommend to enable automatic updates to automaticly keep things somewhat up to date.

Practical implementation

When having access to more than one external network in openstack you should be avare of a couple of limitations:

• An openstack router is only connected to a single external network.
• A openstack subnet is usually only connected to a single openstack router.
• A floating IP of a certain external network can only be attached to a VM connected to a subnet connected to a router with its external interface connected to the same external network.

In practice this means that you should create two openstack networks/subnets/routers when you have access to ntnu-global. One for ntnu-internal and one for ntnu-global. And then connect VM's needing global IP's to the network services by the router connected to ntnu-global, and all other VM's to the other network.

The external networks available varies from cloud to cloud. Currently all clouds have only one external network, but this is likely to change.

skyhigh.hig.no

The skyhigh installation has the following external networks:

• ext-net - 172.16.0.0/16 - An external network which is not routed troughout NTNU. Used for general purpose access to the virtual machines.

skylow.hig.no

The skylow installation (the development platform at Gjøvik) has the following external networks:

• ext-net - 172.18.128.0/17 - An external network which is not routed troughout NTNU. Used for general purpose access to the virtual machines.

stack.it.ntnu.no

The skyhigh installation has the following external networks:

• ntnu-internal - 10.212.24.0/22 - Used for general purpose access to the virtual machines. Accessible from all NTNU networks. Use VPN for external access.

Restricting access to an external network

In the scenario where you need to have limited access to an external network, do the following:

First, find the ID of the external network. Suppose "test-ext" is the network that needs restricted access:

$ openstack network list -c Name -c ID
+--------------------------------------+-------------+
| ID                                   | Name        |
+--------------------------------------+-------------+
| 50a80b8c-d06c-4b53-97f2-6c0b9f9a405c | test-ext    |
| ab6cf6f2-b320-4522-99bf-e5ab65c51553 | admin-lan   |
| dfc8c97d-8cf1-4b4a-9d42-f2cd184b4540 | ext-net     |
+--------------------------------------+-------------+
 

Then remove the RBAC rule with the corresponding object_id . object_id is the network ID. There should only be one RBAC rule with the object_id of the network we are working with here.

$ neutron rbac-list
+--------------------------------------+-------------+--------------------------------------+
| id                                   | object_type | object_id                            |
+--------------------------------------+-------------+--------------------------------------+
| c1d8506f-a9a2-4f93-9921-0a8969dac3d8 | network     | 50a80b8c-d06c-4b53-97f2-6c0b9f9a405c |
| e8abdcf5-1bdd-4087-82bf-26dc08bf0fa1 | network     | dfc8c97d-8cf1-4b4a-9d42-f2cd184b4540 |
+--------------------------------------+-------------+--------------------------------------+
 
$ neutron rbac-delete <id>

Create a new RBAC rule for "test-ext", that states access for given projects only. You need one RBAC rule per project:

...