Introduction
In Apache CloudStack, users are organized into a logical structure of Accounts and Domains. In previous versions of Apache CloudStack each Account had its own resources which could not be shared with other accounts (eg. when a software application from one Account needs to access an application in another account under the same Domain). For this to work, users had to configure their networks with firewall rules, port forwarding, load balancing or private gateways. This method causes considerable network overhead as all packets have to go through 2 different Virtual Routers (VRs) to reach their destination.
With Apache CloudStack 4.17, end-users can connect their instances by adding a new network interface from a different Account under the same Domain, thus simplifying connectivity. Added to that, by limiting the networking to layer 2, overhead is removed as instances are directly connected.
In order to achieve this, CloudStack allows for Guest Networks to be shared with other accounts in the same domain by managing network permissions. You can find more information about network permissions in the official documentation at https://docs.cloudstack.apache.org/en/latest/adminguide/networking/network_permissions.html
Common use cases
Below are some applicable use cases:
• Users want to share an Isolated Network between multiple Accounts, so instances can connect on Layer 2.
• Users want to share an Isolated Network between multiple Accounts, so all Instances can reach internet via the Virtual Router.
• Users want a Guest Network to be used only by certain Accounts.
Understanding Network Permissions
Network Permissions are a list of permissions affiliated to a Guest Network, which allow different Accounts under a same Domain to share a Network. A Network Permission has two properties:
• network_id: The Guest Network id to be shared.
• account_id: A different Account under the same Domain which will be able to access Network.
Network Permissions can be created for the following networks:
• L2 Networks outside Projects
• Isolated Networks outside Projects
• Shared Networks when the scope is “Account”
All other types of networks don’t support Network Permissions, these include:
• Networks in a Project: Users already can add an Account to a Project to access these Networks.
• Shared Networks with scope Domain. These Networks are already shared with all Accounts under the same Domain so, they don’t need additional permissions.
• VPC tiers.
Network Permission can be set to the following Accounts:
• Account in same Domain
• Project in same Domain
A list of allowed / not allowed operations can be found at ” Supported Operations for external Accounts ” section in this article.
Managing Network Permissions
Network Permissions can be managed using the CloudStack API and UI. These are the new API calls introduced to support Network Permission operations:
• createNetworkPermissions
• listNetworkPermissions
• removeNetworkPermissions
• resetNetworkPermissions
Network Permissions can be managed by:
• ROOT admin
• Domain admin
• The owner of the network
Managing Network Permission using UI
Any network, new or existing, can have their permissions managed. To accomplish that, navigate in the UI to “Network” / “Guest Networks”, choose the network you want to manage and then click on “Network Permissions” tab.
Now, click on the “+ Add Network Permission” button to share the target Network to the other accounts. Root Admins and Domain Admins can choose accounts in the dropdown list.
Regular users also can insert accounts typing their names as follow.
Listing Network Permissions
- Click on the icon “Delete Network Permission” of each permission to delete a network permission.
- Click on the icon “Reset Network Permissions” to reset the network permissions, which will remove all existing network permissions.
Supported Operations for external Accounts
When an external Account has permission to use a Network, users under this Account can add NICs to Instances, connecting them to the target Network. However, they can’t perform some operations like restart, update, modify network rules (e.g. firewall, static NAT, load balancer, port forwarding) which are allowed only for the Account owner or Domain Admin.
The following operations / API calls are allowed for users in the external account:
• listNetworks
• addNicToVirtualMachine
• deployVirtualMachine
• destroyVirtualMachine
• expungeVirtualMachine
• listVirtualMachines
• rebootVirtualMachine
• recoverVirtualMachine
• removeNicFromVirtualMachine
• resetPasswordForVirtualMachine
• resetSSHKeyForVirtualMachine
• restoreVirtualMachine
• scaleVirtualMachine
• startVirtualMachine
• stopVirtualMachine
• updateDefaultNicForVirtualMachine
• updateVirtualMachine
• addIpToNic
• listNics
• removeIpFromNic
• updateVmNicIp
The following operations / API calls are NOT allowed:
• Network: Delete/migrate/restart/update Network
• NetworkPermissions: Create/remove/reset/list NetworkPermission
• LoadBalancerRule: create/delete/assignTo/removeFrom LoadBalancerRule
• LoadBalancer: create/delete/update/assignCertTo/removeCertFrom
• LBStickinessPolicy: create/delete/update
• LBHealthCheckPolicy: create/delete/update
• FirewallRule: create/delete/update
• PortForwardingRule: create/delete/update
• EgressFirewallRule: create/delete/update
• RemoteAccessVpn: create/delete/update
• VpnUser: add/list/remove
• IpAddress: associate/disassociate/list/update
• Resource tags: create/delete
When users from external Accounts execute API calls to list the resources listed above, the API will return this successfully, but the results will be empty.
Conclusion
With this feature end-users can deploy networks in a more flexible manner, allowing for more direct connectivity between networks in different accounts, thus reducing both network and provisioning overheads.
The feature available from the Apache CloudStack 4.17 LTS release.
Wei Zhou works as a Software Architect at ShapeBlue. He has many years experience on cloud computing and a passion for various cutting-edge knowledge. Wei works on software design and implementation, as well as resolving issues for customers and community users. Wei has been a committer of the Apache CloudStack project since 2013 and a PMC member since 2017.
