Defining Security Rules
An administrator must configure security rules to control network traffic to and from Big Data Service resources.
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).
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.
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).
- 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.
Ingress Rule 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.