Service providers often have to provide additional services to their cloud tenants. An example is providing licensing services (KMS) for Windows VMs deployed from provider managed catalog or RHEL Satellite servers for licensing and patching Red Hat VMs. The questions is then where to deploy these shared services virtual machines so they are securely available in multitenant environment?
In my older blog post Centralized Logging in vCloud Director Environments I described how a shared vCloud Director external logging network can be used to collect logs from Edge Gateways. So the idea is to use the same network for connection to the shared services VMs (KMS/Satellite) running in Administration Organization. The Edge Gateway can have only 10 interfaces so it is good that we do not waste another one. Let’s have a look at following diagram:
We have 3 organizations and one Org VDC in each – Customer 1, Customer 2 (the tenants) and Admin Organizations (managed by the provider). The tenants connect their vApps to the shared internet network (yellow) via the Edge Gateways by using sub-allocated public addresses (8.8.8.x) utilizing source or destination NAT of their Org VDC network. Each Edge Gateway is connected to another vCloud external network (black) that is using both for Edge logging and access to shared services running in the Admin Organization.
Notice that there are two IP subnet ranges assigned to the service external network. The 10.0.5.0/24 is used solely for the Edge logging. The syslog server sits in this network (10.0.5.254) and firewall infront of it ensures that only Edge logs get there. The Edge Gateway IP from this network (10.0.5.1 and 10.0.5.2) is not sub-allocated for tenant use so they cannot create NAT rules with it. They could only route (one way) from their Org VDC networks and send UDP packets but the syslog firewall denies such traffic as it is coming from internal (192.168.1.2) IPs.
The second IP subnet range of the service network (172.16.254.0/24) is used for the communication to the service VMs running in Admin Organization. So how is this achieved securely?
- The provider sub-allocates the Edge IP to the tenant so he can create NAT rules. So 172.16.254.1 is sub-allocated to Customer 1, 172.16.254.2 is sub-allocated to Customer 2.
- The provider pre-creates SNAT rule for each deployed Edge Gateway. The rule must be applied on the Service network, original IP range is everything 0.0.0.0/0 and translated IP is the sub-allocated IP of the Edge.
![SNAT rule]()
The tenant has to be told not to delete or alter the rule otherwise his access to shared services will not work anymore. - The provider creates destination NAT rule for his service VMs running in Admin Organization. To do this he first needs to have sub-allocated IP addresses (in my example 172.16.254.3 and 172.16.254.4) and then DNATs them to the VM internal IPs 192.168.1.2 and 192.168.1.3. Obviously port forwarding could be used as well to save some IPs as long the port numbers of the services are not the same.
That’s it. Any traffic from the tenant’s VM to the external IP address of the service VM (e.g. 172.16.254.3) will be SNATed by the tenant Edge GW and DNATed by the Admin Edge GW and securely delivered without the tenants being able to contact each other (unless the create DNAT rules as well which could be prevented by MAC ACLs on the external network).
I would also advise to use some obscure IP ranges for the service network so they do not overlap with customer defined Org VDC network ranges.
