Oracle Cloud Infrastructure Documentation

Network Security Groups

The Networking service offers two virtual firewall features to control traffic at the packet level:

  • Network security groups: Covered in this topic. Network security groups are supported only for specific services.
  • Security lists: The original type of virtual firewall offered by the Networking service. See Security Lists.

Both of these features use security rules. For important information about how security rules work, and a general comparison of security lists and network security groups, see Security Rules.

Highlights

  • Network security groups (NSGs) act as a virtual firewall for your compute instances and other kinds of resources. An NSG consists of a set of ingress and egress security rules that apply only to a set of VNICs of your choice in a single VCN (for example: all the compute instances that act as web servers in the web tier of a multi-tier application in your VCN).
  • Compared to security lists, NSGs let you separate your VCN's subnet architecture from your application security requirements. See Comparison of Security Lists and Network Security Groups.
  • You can use NSGs with certain resource types. For more information, see Support for Network Security Groups.
  • NSG security rules function the same as security list rules. However, for an NSG security rule's source (for ingress rules) or destination (for egress rules), you can specify an NSG instead of a CIDR. This means you can easily write security rules to control traffic between two NSGs in the same VCN, or traffic within a single NSG. See Parts of a Security Rule.
  • Unlike with security lists, the VCN does not have a default NSG. Also, each NSG you create is initially empty. It has no default security rules.
  • Network security groups have separate and different limits compared to security lists. See Security List Limits.

Support for Network Security Groups

NSGs are available for you to create and use. However, they are not yet supported by all the relevant Oracle Cloud Infrastructure services.

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 update existing VNICs on an instance so that they are in one or more NSGs.
  • Load balancers: When you create a load balancer, you can specify one or more NSGs for the load balancer (not the backend set). You can also update an existing load balancer to use one or more NSGs.
  • DB systems: When you create a DB system, you can specify one or more NSGs. You can also update an existing DB system to use one or more NSGs.
  • Autonomous Databases: When you create an Autonomous Database on dedicated Exadata infrastructure, you can specify one or more NSGs for the infrastructure resource. You can also update an existing dedicated Exadata infrastructure instance to use NSGs.
  • 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.
  • DNS resolver endpoint: When you create an endpoint for a private DNS resolver, you can specify one or more NSGs. You can also update an existing endpoint to use one or more NSGs.
  • Kubernetes clusters: When you create a Kubernetes cluster using Container Engine for Kubernetes, you can specify one or more NSGs to control access to the Kubernetes API endpoint and to worker nodes. You can also specify NSGs when defining a load balancer for a cluster.
  • API gateways: When you create an API gateway, you can specify one or more NSGs to control access to the API gateway.
  • Functions: When you set up an application in OCI Functions, you can specify one or more NSGs to define ingress and egress rules that apply to all the functions in that particular application.
  • GoldenGate deployments: When you create a GoldenGate deployment, you can specify one or more NSGs to control access to the deployment.

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

Overview of Network Security Groups

A network security group (NSG) provides a virtual firewall for a set of cloud resources 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.

An NSG consists of two types of items:

  • 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 same VCN as the NSG. Also see Comparison of Security Lists and Network Security Groups.
  • Security rules: The NSG'sSecurity rules define the types of traffic allowed in and out of the VNICs in the group. For example: ingress TCP port 22 SSH traffic from a particular source.

If you have resources with different security postures in the same VCN, you can write NSG security rules to control traffic between the resources with one posture versus another. For example, in the following diagram, NSG1 has VNICs running in one tier of a multi-tier architecture application. NSG2 has VNICs running in a second tier. Both NSGs must belong to the same VCN. The assumption is that both NSGs need to initiate connections to the other NSG.

For NSG1, you set up egress security rules that specify NSG2 as the destination, and ingress security rules that specify NSG2 as the source. Likewise for NSG2, you set up egress security rules that specify NSG1 as the destination, and ingress security rules that specify NSG1 as the source. The rules are assumed to be stateful in this example.

You can set up security rules to control traffic between two network security groups.

The preceding diagram assumes that each NSG needs to initiate connections to the other NSG.

The next diagram assumes that you instead want to only allow connections initiated from NSG1 to NSG2. To do that, remove the ingress rule from NSG1 and the egress rule from NSG2. The remaining rules do not allow connections initiated from NSG2 to NSG1.

These security rules allow connections initiated in only one direction: from NSG1 to NSG2.

The next diagram assumes that you want to control traffic between VNICs in the same NSG. To do that, set the rule's source (for ingress) or destination (for egress) as the rule's own NSG.

You can set up security rules to control traffic between VNICs in the same NSG.

A VNIC can be in a maximum of five NSGs. A packet in question is allowed if any rule in any of the VNIC's NSGs allows the traffic (or if the traffic is part of an existing connection being tracked). There's a caveat if the lists happen to contain both stateful and stateless security rules that cover the same traffic. For more information, see Stateful Versus Stateless Rules.

Network security groups are regional entities. For limits related to network security groups, see Comparison of Security Lists and Network Security Groups.

See Network Security Group Limits and Requesting a Service Limit Increase for limits-related information.

Working with Network Security Groups

General Process for Working with NSGs

  1. Create an NSG.
  2. Add security rules to the NSG.
  3. Add parent resources (or more specifically, VNICs) to the NSG. 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. Separately, you can create secondary VNICs and optionally add them to NSGs.

Before deleting an NSG, you must remove all VNICs from it.

See the next sections for more details.

Creating NSGs

Each VCN comes with a default security list that has default security rules in it to enable basic connectivity. However, there is no default NSG in the VCN.

When you create an NSG, it is initially empty, without any security rules or VNICs. If you're using the Console, you can add security rules to the NSG during creation.

You may optionally assign a friendly name to the NSG during creation. It doesn't have to be unique, and you can change it later. Oracle automatically assigns the NSG a unique identifier called an Oracle Cloud ID (OCID) . For more information, see Resource Identifiers.

For the purposes of access control, you must specify the compartment  where you want the NSG to reside. Consult an administrator in your organization if you're not sure which compartment to use. For more information, see Access Control.

Updating Security Rules and Group Membership

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.

If you're familiar with security lists and use the REST API, note that the model for updating existing security rules is different between security lists and NSGs. With NSGs, each rule in a given group has a unique Oracle-assigned identifier (example: 04ABEC). When you call UpdateNetworkSecurityGroupSecurityRules, you provide the IDs of the specific rules that you want to update. For comparison, 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 are not being updated in the call.

When you manage an NSG's VNIC membership, you do it as part of working with the parent resource, not the NSG itself. For more information, see Comparison of Security Lists and Network Security Groups.

Specifying an NSG in a Security Rule

As mentioned earlier in Overview of Network Security Groups, you can specify an NSG as the source (for ingress rules) or destination (for egress rules) in a given NSG's security rule. The two NSGs must be in the same VCN. For example, if both NSG1 and NSG2 belong to the same VCN, you could add an ingress rule to NSG1 that lists NSG2 as the source. If someone deletes NSG2, the rule becomes invalid. The REST API uses an isValid Boolean in the SecurityRule object to convey that status.

Deleting NSGs

To delete an NSG, it must not contain any VNICs or parent resources. When a parent resource (or a compute instance VNIC) is deleted, it is automatically removed from the NSGs it was in. You might not have permission to delete a particular parent resource. Contact your administrator to determine who owns a given resource.

The Console displays a list of parent resources that are in an NSG, with a link to each parent resource. If the parent resource is a compute instance, the Console also displays the instance's VNIC or VNICs that are in the NSG.

To remove a parent resource from its NSGs without deleting the resource, first view the parent resource's details in the Console. There you can see a list of the NSGs that the resource belongs to. From there, you can click Edit and remove the resource from all NSGs. If you're instead working with a compute instance, view the details of the specific VNIC that you want to remove from the NSGs.

If you're using the REST API: the ListNetworkSecurityGroupVnics lists the parent resources and VNICs in an NSG. Use the resource's Update operation to remove the resource from NSGs. For example, for a Compute instance, use the UpdateVnic operation . For a load balancer, use the UpdateNetworkSecurityGroups operation, and so on.

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be granted security access in a policy  by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment  to work in.

For administrators: The policy in Let network admins manage a cloud network covers management of all Networking components, including NSGs.

If you have security admins who need to manage NSGs but not other components in the Networking service, you could write a more restrictive policy: 

Allow group NSGAdmins to manage network-security-groups in tenancy
			
Allow group NSGAdmins to manage vcns in tenancy 
      where ANY {request.operation = 'CreateNetworkSecurityGroup',
                 request.operation = 'DeleteNetworkSecurityGroup'}

Allow group NSGAdmins to read vcns in tenancy

Allow group NSGAdmins to use VNICs in tenancy

The first statement lets the NSGAdmins group create and manage NSGs and their security rules.

The second statement is required because the creation or deletion of an NSG affects the VCN that the NSG is in. The statement restricts the VCN-related permissions to only those required to create or delete an NSG. The statement does not allow the NSGAdmins group to create or delete VCNs, or work with any resources in a VCN except NSGs.

The third statement is required for listing the VCNs, which is a prerequisite for creating or deleting an NSG in a VCN. For information about why both the second and third statements are required, see Conditions.

The fourth statement is required if the NSGAdmins need to put VNICs into an NSG. Whoever creates the parent resource of the VNIC (for example, a Compute instance) must already have this level of permission to create the parent resource.

For more information about Networking service policies, see IAM Policies for Networking.

Using the Console

To view the security rules and resources in an NSG
  1. Open the navigation menu, click Networking, and then click Virtual cloud networks.
  2. Click the VCN you're interested in.
  3. Under Resources, click Network Security Groups.

  4. Click the NSG you're interested in to view its details.

    The NSG's security rules are displayed on the page. From there you can add, edit, or remove rules.

  5. Under Resources, click VNICs to see the parent resources that belong to the NSG.

    If the parent resource is a compute instance, the corresponding VNICs from that instance are also listed on the page.

    For other types of parent resources, the relevant service manages the VNICs on your behalf. Therefore only the parent resource (and not its corresponding VNICs) is listed on the page.

To create an NSG

Prerequisite: Become familiar with the parts of security rules.

  1. Open the navigation menu, click Networking, and then click Virtual cloud networks.
  2. Click the VCN you're interested in.
  3. Under Resources, click Network Security Groups.
  4. Click Create Network Security Group.

  5. Enter the following:

    1. Name: A descriptive name for the network security group. The name doesn't have to be unique, and you can change it later. Avoid entering confidential information.
    2. Create in Compartment: The compartment where you want to create the network security group, if different from the compartment you're currently working in.
    3. Show Tagging Options: If you have permissions to create a resource, then you also have permissions to apply free-form tags to that resource. To apply a defined tag, you must have permissions to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure whether to apply tags, skip this option (you can apply tags later) or ask your administrator.

  6. Click Next.

    If you want to create the NSG without any rules yet, click Create and you're done. Otherwise proceed to the next step.

  7. For the first security rule, enter the following items (for examples of rules, see Networking scenarios):

    • Stateful or stateless: If stateful, connection tracking is used for traffic matching the rule. If stateless, no connection tracking is used. By default, rules are stateful unless you specify otherwise. See Stateful Versus Stateless Rules.
    • Direction (ingress or egress): Ingress is inbound traffic to the VNIC, and egress is outbound traffic from the VNIC.

    • Source Type and Source (for ingress rules only):

      Allowed source types
      Source Type Allowed Source
      CIDR The CIDR block where the traffic originates from. Use 0.0.0.0/0 to indicate all IP addresses. The prefix is required (for example, include the /32 if specifying an individual IP address).
      Service

      Only for packets coming from an Oracle service through a service gateway.

      The source service is the service CIDR label that you're interested in.
      Network Security Group

      An NSG that is in the same VCN as this rule's NSG.

    • Destination Type and Destination (for egress rules only):

      Allowed destination types
      Destination Type Allowed Destination
      CIDR The CIDR block where the traffic is destined to. Use 0.0.0.0/0 to indicate all IP addresses. The prefix is required (for example, include the /32 if specifying an individual IP address).
      Service

      Only for packets going to an Oracle service through a service gateway.

      The destination service is the service CIDR label that you're interested in.
      Network Security Group

      An NSG that is in the same VCN as this rule's NSG.
    • IP Protocol: Either a single IPv4 protocol (for example, TCP or ICMP) or "all" to cover all protocols.
    • Source port range: The port where the traffic originates from. For TCP or UDP, you can specify all source ports, or optionally specify a single source port number, or a range.
    • Destination port range: The port where the traffic is destined to. For TCP or UDP, you can specify all destination ports, or optionally specify a single destination port number, or a range.
    • ICMP type and code: For ICMP, you can specify all types and codes, or optionally specify a single type with an optional code. If the type has multiple codes, create a separate rule for each code you want to allow.
  8. To add another security rule, click + Another Rule and enter the rule's information. Repeat for each rule you want to add.
  9. When you're done, click Create.

The NSG is created and then displayed on the Network Security Group page in the compartment you chose. You can now specify this NSG when creating or managing instances or other types of parent resources.

When you view all the security rules in an NSG, you can filter the list by ingress or egress.

To add or remove a resource from an NSG

In general, you manage the resource membership of an NSG at the parent resource, and not at the NSG itself. In other words, to add a parent resource to an NSG, you execute the action on the parent resource (by specifying which NSGs the parent resource should be added to). You do not execute the action on the NSG (by specifying which VNICs or parent resources should be added to the NSG). Similarly, to remove a VNIC from an NSG, you execute that action by updating the parent resource, not the NSG. For a list of the parent resources that support the use of NSG, see Support for Network Security Groups.

Example: Compute Instances
  • When creating an instance: In the Networking section, under the advanced options, select the check box for Use network security groups to control traffic. Then, specify one or more NSGs. The instance's primary VNIC  is added to the NSGs. See the procedure in Creating an Instance.
  • For an existing instance: Adding an existing instance to an NSG means adding its primary VNIC to the NSG. You can also add a secondary VNIC  to an NSG. See To add or remove a VNIC from a network security group.
Example: Exadata Cloud VM Cluster
  • When creating an Exadata cloud VM cluster: In the Network Information section, you set up the client network and backup network. For each network, select the check box for Use network security groups to control traffic, and then specify one or more NSGs for the specific network. See To create a cloud VM cluster resource. Also see Network Setup for Exadata Cloud Service Instances.
  • For an existing Exadata Cloud Service instance: An Exadata cloud VM cluster's details include a list of the NSGs that the client network belongs to (if any), and a list of the NSGs that the backup network belongs to (if any). Next to the relevant Network Security Groups, click Edit to change that list.
To delete an NSG

Prerequisite: To delete a security list, it must not be associated with a subnet. You can't delete the default security list in a VCN.

  1. Open the navigation menu, click Networking, and then click Virtual cloud networks.
  2. Click the VCN you're interested in.
  3. Under Resources, click Network Security Groups.
  4. For the network security group you want to delete, click the Actions menu, and then click Terminate.
  5. Confirm when prompted.
To manage security rules for an NSG
  1. Open the navigation menu, click Networking, and then click Virtual cloud networks.
  2. Click the VCN you're interested in.
  3. Under Resources, click Network Security Groups.

  4. Click the NSG you're interested in to view its details.

    The NSG's security rules are displayed on the page. From there you can add, edit, or remove rules.

To manage tags for an NSG
  1. Open the navigation menu, click Networking, and then click Virtual cloud networks.
  2. Click the VCN you're interested in.
  3. Under Resources, click Network Security Groups.
  4. Click the NSG you're interested in.
  5. Click the Tags tab to view or edit the existing tags. Or click Add tags to add new ones.

For more information, see Resource Tags.

To move an NSG to a different compartment

You can move an NSG from one compartment to another. When you move an NSG to a new compartment, inherent policies apply immediately.

  1. Open the navigation menu, click Networking, and then click Virtual cloud networks.
  2. Click the VCN you're interested in.
  3. Under Resources, click Network Security Groups.
  4. Click the the Actions menu for the NSG, and then click Move Resource.
  5. Choose the destination compartment from the list.
  6. Click Move Resource.

For more information about using compartments and policies to control access to your cloud network, see Access Control. For general information about compartments, see Managing Compartments.

Using the API

For information about using the API and signing requests, see REST API documentation and Security Credentials. For information about SDKs, see SDKs and the CLI.

To manage a VCN's network security groups, use these operations:

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 (such as UpdateSecurityList). With NSGs, the rules are not part of the NetworkSecurityGroup object. Instead you use separate operations to work with the rules for a given NSG (example: UpdateNetworkSecurityGroupSecurityRules).
  • The model for updating existing security rules is different between security lists and NSGs. With NSGs, each rule in a given group has a unique Oracle-assigned identifier (example: 04ABEC). When you call UpdateNetworkSecurityGroupSecurityRules, you provide the IDs of the specific rules that you want to update. For comparison, 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 are not being updated in the call.
  • There is a limit of 25 rules when calling the operations to add, remove, or update security rules.