Home / Blogs

Cloud Security Hinges on IP Addressing

In the first part of this trilogy, I discussed the importance of automatically provisioned second generation DNS in connection with Software Defined Networking (SDN) and Software Defined Data Centre (SDDC). In the second post, I talked about IP addressing, private enterprise networks, and how DHCP does not meet the requirements of multitenant Infrastructure-as-a-Service (IaaS) cloud environments. I will now wrap up this trilogy by putting these two thesis into real-life context.

Over the last 10 years, the principle of security by design has been gaining popularity within software engineering. This concept should also be incorporated into the SDDC and cloud architectures, to ensure that organizations leveraging the promise of cloud computing will not be compromised for their forward looking thinking.

I guess it would be fair to say that perimeter security is currently the most widely used protection for IT infrastructure. By implementing firewalls, VPNs, intrusion prevention, attack detection and the like, it has been possible to deploy reasonably secure private computing environments. To complement the perimeter security, most organizations are taking further measures inside their enterprise networks, to make sure that threats are promptly detected and dealt with.

With all this in mind, it is no wonder that information security professionals are skeptic about public and hybrid clouding models. After all, both introduce a number of new attack vectors into the secured environments. But what if the hybrid cloud did not require communication with applications and servers running in the public Internet, but rather involved an architecture that was secure by design?

The problem with most IaaS cloud offerings out there today is that their hybrid offering usually relies on public IP addresses. The customers are expected to network to the extra capacity over the Internet. While this may be an easy solution for an IaaS cloud provider leveraging standard cloud stacks and DHCP, the publicly routed IP addresses assigned to the workloads introduce a new attack vector to the end-user’s private network environment.

The simplest way to overcome this security issue is to create a secure tunnel between the IaaS cloud and its end-users’ enterprise networks, and to assign every single workload an IP address that matched with the IP addressing scheme used in end-users’ private networks. While Cisco says that VXLAN is intended for intra data center connectivity only, for example VPN could be used for tunneling just as well.

This straightforward solution brings about two major benefits. First, since the IP addresses in the IaaS cloud are part of every end-user’s own IP addressing scheme, the hosts will have no trouble networking between the cloud and the enterprise network back home. Second, if the VLANs in which the workloads are deployed are not routed to the public Internet at all, they will be less prone to various security threats lurking there.

When an IP addressing model described above is merged with a dynamic DNS provisioning engine, the outcome becomes extremely powerful. After all, what organization would not want to tap into is the economics of an IaaS cloud, knowing that it was as secure as their enterprise network. This proposition becomes even more compelling when the workloads have names and IP addresses that match with end-users’ own enterprise networks, making the IaaS cloud a transparent extension of one’s own computing resources.

In the context of orchestrated cloud application deployment, the technologies I’ve outlined in this trilogy are generally related to release parameters. So rather than talking about DHCP, IP addressing or DNS as isolated technologies, I argue that they should be merged into automated and holistic Release Parameter Provisioning (RPP). More importantly, rather than trying to make cloud orchestration solutions perform tasks they are not good at, I claim that RPP merits its own layer in the SDDC and cloud stacks, functioning as a neat bridge between the SDN and the cloud orchestration layers.

By Juha Holkkola, Co-Founder and Chief Executive at FusionLayer Inc.

Juha Holkkola is the Co-Founder and Chief Technologist at FusionLayer Inc. An inventor with several patents in the US and Europe, he is an advocate of technology concepts with tangible operational impact. Juha is an active proponent of emerging technology trends such as cloud computing, hybrid IT and network functions virtualization, and a regular speaker at various industry events.

Visit Page

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Threat Intelligence

Sponsored byWhoisXML API


Sponsored byVerisign


Sponsored byDNIB.com

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix

Domain Names

Sponsored byVerisign