OCI Classic – Reference Architecture

I’ve spent some time helping customers move their workloads to Public Clouds. Public clouds such as Oracle Cloud Infrastructure (OCI) Classic. OCI Classic is the original public cloud offering by Oracle – which now has a complementary offering – Oracle Cloud Infrastructure (OCI).

OCI Classic has unique features when compared to other public cloud environments like AWS, Azure and Google Cloud Platforms. With OCI Classic, you get a rich set of networking and firewall capabilities that give granular control. But with granular control comes the need to have a good reference architecture in implementing scalable application tiers.This article focuses on designing a solid reference architecture on OCI Classic platform.

It is assumed that the reader has some good knowledge about cloud computing and some background knowledge on Oracle Cloud Infrastructure (OCI) Classic. Our aim in this article is to implement the reference architecture shown in the diagram below.

Before customers can migrate their on-premise Data Centre workloads to the cloud, they need a solid Infrastructure as a Service (IaaS) reference architecture. We will now take a look at a basic reference architecture on OCI Classic cloud platform.


Let’s break down the reference architecture into its main components.

1) A 3 Tier Application model showing the Front End Tier, Middle Tier and the Database Tier
2) A Bastion Server which in this example is just a Windows Server 2012
3) A Reverse Proxy that allows us to access a published web application located on an internal network
4) A Forward Proxy which can be used for outbound internet access for HTTP, HTTPS, and FTP protocols


The reference architecture provides a guide on how to set up a basic 3 Tier Application model in OCI Classic – in a secure and scalable way.

Each Tier is in its own separate IP Network. An IP network is simply an IP subnet. Each Tier is also grouped in its own vNICset. A vNICset is a logical construct that allows us to group cloud virtual machine instances in order to apply certain operations to the group – such as Access Control Lists (ACL) etc.

In OCI Classic cloud, we have an IP Exchange – which is essentially a virtual router in the cloud that connects all IP Networks (subnets) together. The IP Exchange ensures that there is layer 3 network reachability to all IP Networks that are attached to it.


Design Goals

We want to establish the following connectivity between the different components of the architecture:

1) RDP Access from Internet to Bastion Network
2) SSH Access from the Bastion Network to Front End, Middle Tier, Database Tier, Reverse Proxy and Forward Proxy Networks
3) Forward Proxy Access to Internet for cloud instances in Front End, Middle Tier, and Database Tier IP Networks
4) HTTP(S) Reverse Proxy Access to Front End Network from Internet
5) HTTP Access to Middle Tier Network from Front End Network
6) SQL*Net Access from Middle Tier Network to Database Tier Network


Egress Security Rules

The egress security rule for all instances can be set to ‘Allow all’ egress traffic. This illustrates how cloud network security and defense-in-depth could be viewed from an ingress perspective, i.e. you can set the egress rules on all instances in the cloud to allow all egress traffic, and then apply appropriate ingress rules on the individual instances to permit only allowed traffic. We will view each of the associated ingress rules later in the article.


RDP and SSH Access

In order manage your cloud resources securely, you can use RDP or SSH connection to connect to your cloud virtual machine instances. In this simple scenario, we are using an RDP session from an on-premise server (with IP address a.b.c.d) to access the Bastion Server located in the Oracle cloud. From the Bastion Server, we can now SSH into all other instances within the cloud network.

Below, we show the various security rules under the ACLs for each of the components of the cloud network.

Security Rule Naming DDD_SSS_PPP_In (e.g. Bast_Internet_RDP_In)

DDD = Destination IP Address or Network
SSS = Source IP Address or Network
PPP = Protocol Type
In = Ingress

For example, Bast_Internet_RDP_In security rule implies that we create a security rule under the ACL Bastion_ACL that allows RDP connections from the on-premise Server IP address a.b.c.d. It is possible to allow RDP sessions from all IP addresses by not specifying the source IP prefix, but this could be a security concern – and hence, we would rather use the best practice recommendation of allowing only specific hosts that need RDP access.

The security rule FE_Bast_SSH_In implies that we create a security rule under the ACL FE_ACL that allows SSH connections coming from only the Bastion Network and with a destination of for the Front End (FE) Network. SSH traffic is allowed at the egress of the Bastion Server to all other cloud instances because of the ‘Allow All’ egress security rule explained earlier.


DB Access from Middle Tier

An ACL and Security Rule should be created to allow SQL*Net traffic from the Middle Tier to the Database Tier. This follows the same idea for the ACL and security rule for RDP and SSH connections. SQL*Net traffic is allowed at the egress of the Middle-tier because of the ‘Allow All’ egress security rule explained earlier. It is normally expected that the database listener port is 1521 so the ingress security rule applied to the database tier should allow TCP port 1521 connections from the Middle Tier IP Network.

In addition to SQL*Net traffic from the Middle Tier, a customer might also want to allow all ports associated with Oracle Enterprise Manager used to manage the database. Security Rules allowing the additional ports would have to be added.


Middle Tier Access From Front End

An ACL and Security Rule should be created to allow HTTP traffic from the Front End to the Middle Tier. This follows the same idea for ACL and security rule as described for SQL*Net traffic from Middle Tier to Database Tier. HTTP traffic is allowed at the egress of the Front End tier because of the ‘Allow All’ egress security rule explained earlier. The ingress security rule applied to the ACL of the Middle Tier should allow only TCP port 80 connections from the Front End IP Network.


Reverse Proxy

The Reverse Proxy accepts HTTPS connections from the internet. HTTPS traffic is allowed into the Reverse Proxy Network via the Security Rule configured on the ACL. The reverse proxy terminates the HTTPS (port 443) connections from the internet and initiates a new HTTP (port 80) connection to the Front End instance.

HTTPS connections towards the internet are allowed out of the Reverse Proxy IP Network because of the ‘Allow All’ egress security rule explained earlier. The security rule of the Front End network allows HTTP traffic coming from the Reverse Proxy network only.


Forward Proxy

The Forward Proxy should be configured to accept web traffic from the Front End, Middle Tier and Database Tier networks; and redirect the traffic to the internet. This means a forward proxy network ACL Security Rule should be configured to allow ingress TCP Port 8080 traffic originating from the internal IP Networks. The Forward Proxy can be used for HTTP, HTTPS and FTP proxying.

The Front End, Middle Tier, and Database Tier networks can all send TCP Port 8080 traffic because of the ‘Allow All’ egress security rule explained earlier.

Note that Proxy servers should be hardened to improve their security posture. This means you should put in place, mechanisms to ensure that only the correct hosts and internal IP Networks are allowed to use the Proxy Server.

Also, the diagram shows Apache Forward Proxy which is a relatively simple proxy ideal for testing purposes. For production networks, it is recommended to use Squid Proxy which more advanced features including caching.


Terraform – Implementing the Scenario

This scenario can be implemented manually on the OCI Classic web console. But instead, I have implemented it using Terraform based on recommended Infrastructure as a Code (IAC) principles. For the Terraform implementation, I have used the modified diagram below. It is still functionally the same solution described earlier in the article, with only the 3 Tier architecture collapsed into a single VM instance. The VM instance runs a simple Apache Web Server – serving a default HTML page.

You can see more about the Terraform implementation in this article – Oracle Cloud Infrastructure Classic – A Terraform Implementation.

Leave a Reply

Your email address will not be published. Required fields are marked *