Oracle Cloud Infrastructure Documentation

Network Security Groups

On Compute Cloud@Customer, a network security group (NSG) provides a virtual firewall for a set of cloud resources, within a single VCN, that all have the same security posture. For example: a group of compute instances that all perform the same tasks and thus all need to use the same set of ports.

Rules in an NSG are enforced on VNICs, but their NSG membership is determined through their parent resources. Not all cloud services support NSGs. Currently, the following types of parent resources support the use of NSGs:

  • Compute instances: When you create an instance, you can specify one or more NSGs for the instance's primary VNIC. If you add a secondary VNIC to an instance, you can specify one or more NSGs for that VNIC. You can also change the NSG membership of existing VNICs.

  • Mount targets: When you create a mount target for a file system, you can specify one or more NSGs. You can also update an existing mount target to use one or more NSGs.

For resource types that do not yet support NSGs, continue to use security lists to control traffic to and from those parent resources.

An NSG contains two types of elements:

  • VNICs: One or more VNICs; for example, the VNICs attached to the set of compute instances that all have the same security posture. All the VNICs must be in the VCN that the NSG belongs to. A VNIC can be in a maximum of five NSGs.

  • Security rules: Rules that define the types of traffic allowed into and out of the VNICs in the group. For example: ingress TCP port 22 SSH traffic from a particular source.

The general process for working with NSGs is as follows:

  1. Create an NSG.

    When you create an NSG, it is initially empty, without any security rules or VNICs. After the NSG is created, you can add or remove security rules to allow the types of ingress and egress traffic that the VNICs in the group require.

  2. Add security rules to the NSG.

  3. Add parent resources, or more specifically VNICs, to the NSG.

    When you manage an NSG VNIC membership, you do it as part of working with the parent resource, not the NSG itself. You can do this when you create the parent resource, or you can update the parent resource and add it to one or more NSGs.

    When you create a compute instance and add it to an NSG, the instance's primary VNIC is added to the NSG. You can create secondary VNICs separately, and optionally add them to NSGs.

There are some differences in the REST API model for NSGs compared to security lists:

  • With security lists, there is an IngressSecurityRule object and a separate EgressSecurityRule object. With network security groups, there is only a SecurityRule object, and the object's direction attribute determines whether the rule is for ingress or egress traffic.

  • With security lists, the rules are part of the SecurityList object, and you work with the rules by calling the security list operations; for example: UpdateSecurityList. With NSGs, the rules aren't part of the NetworkSecurityGroup object. Instead you use separate operations to work with the rules for a particular NSG; for example: UpdateNetworkSecurityGroupSecurityRules.

  • The model for updating existing security rules is different between security lists and NSGs. With NSGs, each rule in a particular group has a unique identifier. When you call UpdateNetworkSecurityGroupSecurityRules, you provide the IDs of the specific rules that you want to update. With security lists, the rules have no unique identifier. When you call UpdateSecurityList, you must pass in the entire list of rules, including rules that aren't being updated in the call.

  • There is a limit of 25 rules when calling the operations to add, remove, or update security rules.