1. Using Oracle Cloud Infrastructure Compute Classic
  2. Configuring the Shared Network

10 Configuring the Shared Network

Topics

About Network Settings

You can implement fine-grained control over network access to your Compute Classic instances, both from other instances as well as from external hosts. When you create an instance, by default, it doesn’t allow access from any other instance or external host. Network settings allow you to configure access to your instances.

You can configure network access to your instance by using the shared network as well as by setting up your own IP networks. If an instance has multiple vNICs, you can associate that instance with both the shared network and the IP network. In the shared network, access to your instances is determined by security lists and security rules, while in the IP network you create security rules and access control lists (ACLs) enable access to instances.

If you want to access an instance directly over the public Internet, you must assign a public IP address to the instance. Public IP addresses can be assigned to the instance interface on the shared network as well as to its interfaces IP networks, if any.

Note:

This section describes network configuration in the shared network. For information about setting up an IP network, see Configuring IP Networks.

In the shared network, to enable unrestricted communication among some of your instances (for example, to enable all the instances hosting your development environment to communicate with each other), you can create a security list and add the instances to that security list. When you add an instance to a security list, the instance can communicate with all the other instances in the same security list using their private IP addresses.

By default, the instances in a security list are isolated from hosts outside the security list. You can override this default setting by creating security rules. Each security rule defines a specific source, a destination, and a protocol-port combination over which communication is allowed. For example, you can set up a security rule to permit SSH access over port 22 from a set of external hosts (specified in a security IP list) to all the instances in a security list.

A security list can be used as a source or destination in up to 10 security rules.

The following diagram illustrates how you can use security lists and security rules to restrict traffic between your instances and control access to them.

Communication paths between security lists and security IP lists using security rules
This diagram shows the following communication paths:

  • Instances in Security-list-a can send traffic to instances in Security-list-b over any protocol, as defined by Security-rule-a.

  • Instances in Security-list-a can receive HTTPS traffic from any host on the public internet, as defined by Security-rule-b.

  • Instances in Security-list-b can receive traffic over SSH from any of the IP addresses specified in Security-IP-list-a, as defined by Security-rule-c.

If no security rules are defined for a security list, then, by default, instances in that security list can’t receive traffic from hosts outside the security list. However, instances in the security list can still access other instances in the same security list.

When you remove an instance from a security list, the instance can no longer communicate with other instances in that security list, and traffic to and from that instance is no longer controlled by the security rules defined for that security list.

A security IP list specifies a set of IP addresses that can be used as a source or a destination in security rules. See Managing Security IP Lists.

An instance can be added to multiple security lists. In case of conflicts in policy, the most restrictive policy takes precedence. For example if an instance belongs to one security list with the outbound policy permit and the same instance is added to another security list with the outbound policy deny, effectively the outbound policy for that instance would be deny.

See Also:

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