Oracle Cloud Infrastructure Documentation

Defining Security Rules

An administrator must configure security rules to control network traffic to and from Big Data Service resources.

Background

In Oracle Cloud Infrastructure, two kinds of virtual firewalls are available for controlling traffic to and from your cloud resources. Security lists include security rules that apply to an entire subnet. Network security groups include security rules that apply to a defined set of resources that are organized into groups. Network security groups allow finer-grained control, while security lists are easier to set up and maintain.

Security lists and network security groups both include security rules. A security rule allows a particular type of traffic in or out of a Virtual Network Interface Card (VNIC).

Note

A VNIC is a networking component that enables a networked resource such as an instance (a node in Big Data Service) to connect to a virtual cloud network (VCN). The VNIC determines how the instance connects with endpoints inside and outside the VCN. Each VNIC resides in a subnet in a VCN. A security list defines a set of security rules that apply to all the VNICs in a subnet. A network security group defines a set of security rules that apply to a group of VNICs that you define.

It's important to understand the role of VNICs in your network architecture, but for the purposes of this documentation, it's usually sufficient to refer how security rules work in VCNs and subnets.

For more information see Security Rules.

Creating Security Rules in Security Lists

Typically, Big Data Service uses security lists. That means that you create security rules for a subnet, and any cluster in that subnet is subject to those rules. The following instructions tell how to create security rules in a security list defined for the subnet used by your cluster.

A security list can define both ingress rules (for incoming traffic) and egress rules (for outgoing traffic).

Each security rule specifies:
  • Direction (ingress or egress)
  • Stateful or stateless
  • Source type and source (ingress rules only)

For complete documentation about security rules, see Parts of a Security Rule.

The following sections contain specific details about creating ingress and egress rules for Big Data Service clusters.

Creating Ingress Rules (and Open Ports)

You must open certain ports on Big Data Service clusters to allow access to services like Apache Ambari, Cloudera Manager, and Hue. Configure these ports in the security ingress rules that apply to a cluster.

For information on creating an ingress rule, see Security Rules with the following content specific for Big Data Service:
  1. In the Add Ingress Rules dialog box, set the following options to open port 22 for SSH access (if it isn't already open):
    • Stateless: Leave this box unchecked. This makes the rule stateful, which means that any response to the incoming traffic is allowed back to the originating host, regardless of any egress rules applicable to the instance.
    • Source Type: Select CIDR.
    • Source CIDR: Enter 0.0.0.0/0, which indicates that traffic from all sources on the internet is allowed.
    • IP Protocol: Select TCP.
    • Source Port Range: Accept the default All.
    • Destination Port Range: Enter 22, to allow access through SSH.
    • Description: Add an optional description.
  2. At the bottom of the dialog box, click +Another Ingress Rule, and enter the values for another rule. Do this for as many times as necessary, to create all the rules you need, and then click Add Ingress Rules.

    For additional information on Ingress rule destination port ranges and rule examples, see Ingress Rule Destination Port Ranges

Ingress Rule Destination Port Ranges

For a typical set of ingress rules for a cluster, create rules with the specified Destination Port Ranges:
  • SSH - port 22
  • Apache Ambari - port 7183
  • Cloudera Manager - port 7183
  • Hue - port 8888
  • Web Resource Manager - port 8090
  • Spark History Server - port 18088
  • Cloud SQL (if Cloud SQL is installed) - port 1521

The ingress rules look similar to the following:

Creating Egress Rules

When creating a cluster, you have the option to use a NAT gateway or not. Whether you choose that option affects how you can control outbound traffic.

  • If you choose the NAT gateway option when creating a cluster, all nodes have full outbound access to the public internet. You can't limit that access in any way (for example by restricting egress to only a few IP ranges).

  • If you choose not to create a NAT gateway when creating a cluster, you can create a NAT gateway on the VCN you're using to access the cluster. You can also edit policies on this NAT gateway to limit egress to specified IP ranges.

  • If you map the VM IPs onto public IPs then a NAT gateway isn't needed.

For information on creating an egress rule, see Security Rules.