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.
  • At this time, you can use NSGs with Compute instances, load balancers, and DB systems. 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 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 using the dedicated deployment option, you can specify one or more NSGs. You can also update an existing dedicated deployment to use NSGs.

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 (as illustrated in the following diagram):

  • 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. Also see About VNICs and Parent Resources.
  • Security rules: Security rules that 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.

A network security group includes VNICs and security rules.

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 Limits.

Security Rules

If you're not yet familiar with the basics of NSG security rules, see these sections in the security rules topic:

Working with Network Security Groups

Warning

Avoid entering confidential information when assigning descriptions, tags, or friendly names to your cloud resources through the Oracle Cloud Infrastructure Console, API, or CLI.

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 An Oracle-assigned unique ID called an Oracle Cloud Identifier (OCID). This ID is included as part of the resource's information in both the Console and API.. For more information, see Resource Identifiers.

For the purposes of access control, you must specify the A collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization. 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 About VNICs and Parent Resources.

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 given the required type of access in a An IAM document that specifies who has what type of access to your resources. It is used in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named "policy" document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources. written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you try to perform an action and get a message that you don’t have permission or are unauthorized, confirm with your administrator the type of access you've been granted and which A collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization. you should 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

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 of an NSG affects the VCN that the NSG is in. The scope of the second statement also allows the NSGAdmins group to create VCNs. However, the group can't create subnets or manage any other components related to any of those VCNs (except for the NSGs), because additional permissions would be required for those resources. The NSGAdmins group also can't delete any existing VCNs that already have subnets in them, because that action would require permissions related to subnets.

The third 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, see IAM Policies for Networking.

Using the Console

To view the security rules and resources in an NSG
To create an NSG
To add or remove a resource from an NSG
To delete an NSG
To manage security rules for an NSG
To manage tags for an NSG
To move an NSG to a different compartment

Using the API

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

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.