Setting Up Networking for a Sample Scenario Using the Shared Network

This section illustrates how you can use security lists and security rules to create firewalls and open ports in a sample topology where several Compute Classic Linux instances are attached to the shared network.

Scenario

In this scenario, you’ll create a topology with eight Compute Classic Linux instances: four used for development (dev1 through dev4) and four for production (prod1 through prod4).

Let’s assume that you have the following firewall requirements:

Requirement Source Destination Protocol and Port Policy

1

Any development instance

Any development instance

All

Allow traffic

2

Any development instance

Any production instance

SSH/22

Allow traffic

3

Any production instance

Any production instance

All

Allow traffic

4

Any production instance

Any development instance

All

Deny traffic

5

Any development instance

Internet

All

Deny traffic

6

Internet

Any development instance

All

Deny traffic

7

Any host in the subnets 203.0.113.1/28 and 203.0.113.32/28

Instances dev3 and dev4

SSH/22

Allow traffic

8

Internet

Any production instance

HTTPS/443

Allow traffic

The following graphic illustrates the required communication routes between your production and development instances and from external hosts over the public Internet.


This figure shows the required firewalls and communication routes between your production and development instances.

To implement these firewall rules using the web console, see Procedure Using the Web Console.

To implement these firewall rules using orchestrations, see Procedure Using Orchestrations v1.

For a graphic showing the topology with the firewall rules implemented, see Network Topology with the Required Firewall Rules Implemented.

Procedure Using the Web Console

To create the required instances and set up the required security rules for this scenario, complete the following tasks:

  1. Generate at least one SSH key pair and upload the SSH public key to Compute Classic. See Generating an SSH Key Pair and Adding an SSH Public Key.

  2. Reserve public IP addresses for the instances that will be accessed over SSH: dev3, dev4, prod1, prod2, prod3, and prod4.

    See Reserving a Public IP Address.

  3. Create the following security lists, as described in Creating a Security List.
    Security List Inbound Policy Outbound Policy

    dev

    Deny

    Deny

    dev_allow_access

    Deny

    Deny

    prod

    Deny

    Deny

  4. Create a bootable storage volume for each of your instances, as described in Creating a Bootable Storage Volume.

  5. Create your instances. Remember to associate an SSH public key and a public IP address with each of the instances that you will access over SSH: dev3, dev4, prod1, prod2, prod3, and prod4. See Creating Instances.

  6. Add your instances to the required security lists as follows:
    • Add dev1 and dev2 to the dev security list.

    • Add dev3 and dev4 to the dev and the dev_allow_access security lists.

    • Add prod1, prod2, prod3, and prod4 to the prod security list.

    See Adding an Instance to a Security List.

    Adding all the development instances to the dev security list enables all instances in the development environment to communicate with each other over any protocol. By default, no host outside this security list can communicate with any development instance, and no development instance can communicate with any host outside this security list. This fulfils firewall requirements 1, 4, 5, and 6.

    Adding all the production instances to the prod security list enables all instances in the production environment to communicate with each other over any protocol. This fulfils firewall requirement 3.

  7. Create a security IP list named ip_list1 consisting of the subnets 203.0.113.1/28 and 203.0.113.32/28. See Creating a Security IP List.

  8. Create the following security rules, as described in Creating a Security Rule.

    Security Rule Parameters Description

    dev-to-prod

    Security application: ssh

    Source security list: dev

    Destination security list: prod

    Any development instance can communicate over SSH with any production instance.

    This fulfils firewall requirement 2.

    iplist-to-dev

    Security application: ssh

    Source security IP list: ip_list1

    Destination security list: dev_allow_access

    Any host in the 203.0.113.1/28 and 203.0.113.32/28 subnets can connect to instances dev3 and dev4 using SSH.

    This fulfils firewall requirement 7.

    internet-to-prod

    Security application: https

    Source security IP list: public-internet

    Destination security list: prod

    Any host on the Internet can send HTTPS requests to any production instance.

    This fulfils firewall requirement 8.

Procedure Using Orchestrations v1

  1. Generate at least one SSH key pair and upload the SSH public key to Compute Classic. See Generating an SSH Key Pair and Adding an SSH Public Key.

  2. Reserve public IP addresses for the instances that will be accessed over SSH: dev3, dev4, prod1, prod2, prod3, and prod4 . You can use the following sample orchestration to reserve public IP addresses. This sample shows you how to reserve two public IP addresses. Use a similar JSON construct to reserve another four IP addresses.

    {
      "name": "/Compute-acme/joe/myIPreservations",
      "oplans": [
        {
          "label": "My IP reservations",
          "obj_type": "ip/reservation",
          "objects": [
            {
              "name": "/Compute-acme/joe/ipres1",
              "parentpool": "/oracle/public/ippool",
              "permanent": true
            },
            {
              "name": "/Compute-acme/joe/ipres2",
              "parentpool": "/oracle/public/ippool",
              "permanent": true
            },
            <Add more IP reservations here.>
          ]
        }
      ]
    }
    
  3. Create the following security lists.
    Security List Inbound Policy Outbound Policy

    dev

    Deny

    Deny

    dev_allow_access

    Deny

    Deny

    prod

    Deny

    Deny

    You can use the following sample orchestration to create security lists. This sample shows you how to create the dev security list. Use a similar JSON construct to create another two security lists.

    {
      "name": "/Compute-acme/joe/mySecurityLists",
      "oplans": [
        {
          "label": "seclists",
          "obj_type": "seclist",
          "objects": [
            {
              "name": "/Compute-acme/joe/dev",
              "outbound_cidr_policy": "deny"
            },
            <Add more security lists here.>
          ]
        }
      ]
    }
    
  4. Create a bootable storage volume for each of your instances. You can use the following sample orchestration to create storage volumes. This sample shows you how to create one storage volume. Use a similar JSON construct to create all the required storage volumes.

    {
      "name": "/Compute-acme/joe/myStorageVolumes",
      "oplans": [
        {
          "label": "My storage volumes",
          "obj_type": "storage/volume",
          "objects": [
            {
              "name": "/Compute-acme/joe/boot",
              "bootable": true,
              "imagelist": "/oracle/public/OL_7.2_UEKR3_x86_64",
              "properties": ["/oracle/public/storage/default"],
              "size": "22548578304"
            },
            <Add more bootable storage volumes here.>
          ]
        }
      ]
    }
    

    Note:

    Don’t define storage volumes and instances in the same orchestration. By keeping storage volumes and instances in separate orchestrations, you can shut down and start the instances when required and yet preserve the attached storage volumes. Note that the recommendation here is to define the storage volumes outside the instance orchestration. To ensure that the storage volumes remain attached after an instance is re-created, you must define the storage attachments within the instance orchestration.

  5. Create your instances. Remember to associate an SSH public key and a public IP address with each of the instances that you will access over SSH: dev3, dev4, prod1, prod2, prod3, and prod4. You can also specify the security lists that you want to add each instance to. Add your instances to the required security lists as follows:

    • Add dev1 and dev2 to the dev security list.

    • Add dev3 and dev4 to the dev and the dev_allow_access security lists.

    • Add prod1, prod2, prod3, and prod4 to the prod security list.

    Adding all the development instances to the dev security list enables all instances in the development environment to communicate with each other over any protocol. By default, no host outside this security list can communicate with any development instance, and no development instance can communicate with any host outside this security list. This fulfils firewall requirements 1, 4, 5, and 6.

    Adding all the production instances to the prod security list enables all instances in the production environment to communicate with each other over any protocol. This fulfils firewall requirement 3.

    You can use the following sample orchestration to create your instances. This sample shows you how to create the dev3 instance, and associate an SSH public key and a public IP address with the instance. This sample orchestration also shows you how to add this instance to the required security lists, dev and dev_allow_access. Use similar JSON constructs to define each of the required instances.

    {
      "name": "/Compute-acme/joe/myInstances",
      "oplans": [
        {
          "label": "My instances",
          "obj_type": "launchplan",
          "objects": [
            {
              "instances": [
                {
                  "name": "/Compute-acme/joe/dev3",
                  "shape": "oc3",
                  "boot_order": [1],
                  "label": "dev3",
                  "networking": {
                    "eth0": {
                      "seclists": ["/Compute-acme/joe/dev", "/Compute-acme/joe/dev_allow_access"],
                      "nat": "ipreservation:/Compute-acme/joe/ipres1"
                    }
                  },
                  "sshkeys": ["/Compute-acme/joe/key1"],
                  "storage_attachments": [
                    {
                      "index": 1,
                      "volume": "/Compute-acme/joe/boot"
                    }
                  ]
                },
                <Add more instances here.>
              ]
            }
          ]
        }
      ]
    }
  6. Create a security IP list named ip_list1 consisting of the subnets 203.0.113.1/28 and 203.0.113.32/28. You can use the following sample orchestration to create your security IP list.

    {
      "name": "/Compute-acme/joe/mySecipLists",
      "oplans": [
        {
          "label": "secip-list",
          "obj_type": "seciplist",
          "objects": [
            {
              "name": "/Compute-acme/joe/ip_list1",
              "secipentries": ["203.0.113.1/28", "203.0.113.32/28"]
            }
          ]
        }
      ]
    }
    
  7. Create the following security rules.

    Security Rule Parameters Description

    dev-to-prod

    Security application: ssh

    Source security list: dev

    Destination security list: prod

    Any development instance can communicate over SSH with any production instance.

    This fulfils firewall requirement 2.

    iplist-to-dev

    Security application: ssh

    Source security IP list: ip_list1

    Destination security list: dev_allow_access

    Any host in the 203.0.113.1/28 and 203.0.113.32/28 subnets can connect to instances dev3 and dev4 using SSH.

    This fulfils firewall requirement 7.

    internet-to-prod

    Security application: https

    Source security IP list: public-internet

    Destination security list: prod

    Any host on the Internet can send HTTPS requests to any production instance.

    This fulfils firewall requirement 8.

    You can use the following sample orchestration to create your security rules. This sample shows you how to create the iplist-to-dev security rule. Use a similar JSON construct to create another two security rules.
    {
      "name": "/Compute-acme/joe/mySecRules",
      "oplans": [
        {
          "label": "My security rules",
          "obj_type": "secrule",
          "objects": [
            {
              "name": "/Compute-acme/joe/iplist-to-dev",
              "application": "/oracle/public/ssh",
              "src_list": "seciplist:/Compute-acme/joe/ip_list1",
              "dst_list": "seclist:/Compute-acme/joe/dev_allow_access",
              "action": "PERMIT"
            },
            <Add more security rules here.>
          ]
        }
      ]
    }
    

After you’ve created all the required orchestrations, upload and start your orchestrations to create the required objects and instances. See Uploading an Orchestration v1 and Starting an Orchestration v1.

Remember that you must define relationships for objects referenced by another object in the same orchestration. For example, if you create IP reservations or security lists and instances in the same orchestration, you must define relationships to ensure that the required IP reservations and security lists are created before the instances that use them. Similarly, if you create security lists or security IP lists and security rules in the same orchestration, define relationships to ensure that the security lists and security IP lists are created before the security rules that use them. See Relationships Between Object Plans.

Network Topology with the Required Firewall Rules Implemented

The following graphic shows the topology with the security rules, security lists, and security IP list set up to enable the network communication required for the scenario described earlier.


Final topology showing the security lists and security rules set up to enable the communication routes described in this sample scenario