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 (NSGs) 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.

Note

You can use Zero Trust Packet Routing (ZPR) along with or in place of network security groups to control network access to OCI resources by applying security attributes to them and creating ZPR policies to control communication among them. For more information, see Zero Trust Packet Routing.

Caution

If an endpoint has a ZPR security attribute, traffic to the endpoint must satisfy ZPR rules as well as all NSG and security list rules. For example, if you're already using NSGs and you apply a security attribute to an endpoint, as soon as the attribute is applied, all traffic to the endpoint is blocked. From then onward, a ZPR policy must allow traffic to the endpoint.

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:

Autonomous Recovery Service (Subnets for Recovery Service): When you register a Recovery Service subnet, you can associate one or more NSGs (maximum five) that contain the ingress rules for Recovery Service.
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 Kubernetes Engine, 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.
Redis clusters: When you create a Redis cluster, you can specify one or more NSGs to control access to the Redis cluster. You can also update an existing cluster to use one or more 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:

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.

Security Rules

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

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.

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.

Working with Network Security Groups

General Process for Working with NSGs

Create an NSG.
Add security rules to the NSG.
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.

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.

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.

Oracle Cloud Infrastructure Documentation