Network policies

Block policy

Specifies a type of policy that prevents you from the following:

• Connecting to the NPSaaS database by using any device or service.

• Connecting from the NPSaaS database to any device or service that has either the specified hostname or an IP address in the range that is specified by CIDR.

Allow policy

Specifies a policy that allows you to do the following:

• Connecting to the NPSaaS database by using any device or service.

• Connecting from the NPSaaS database to any device or service that has either the specified hostname or an IP address in the range that is specified by CIDR.

You can use the combination of allow and block (deny) policies to restrict connections to and from the NPSaaS database to the provided set of IP addresses and hostnames.

Defining network policies with Classless Inter-Domain Routing (CIDR)

With NPSaaS, you can specify a range of IP addresses by using Classless Inter-Domain Routing (CIDR) in network policies.

A CIDR notation is a compact representation of an IP address and its associated network mask.

<ip_address>/<prefix_length>

For example, 76.168.0.0/24 represents IP addresses in the range of 76.168.0.0 and 76.168.0.62

0.0.0.0/0 is a special case of a CIDR notation, which is allowed. Use it with caution because of the following reasons:

• When you use 0.0.0.0/0 as a block policy, all traffic to and from your NPSaaS database is restricted.

• When you use 0.0.0.0/0as an allow policy, all traffic to and from your NPSaaS database is allowed.

You can use CIDR ranges to represent public and private IP addresses. Devices or services that are in a private or enterprise network that uses private IP addresses have gateways. These gateways typically have network interfaces with public IP addresses, which do network address translation (NAT). This allows entities in the private network to connect to external services.

You must use a CIDR range that represents only the public IP addresses of gateways when you are setting allow and block policies.

Do not specify a CIDR range that represents private IP addresses space as block policies. You might impact the functioning of the database.

Defining network policies with DNS hostnames

With NPSaaS, you can specify DNS hostnames in network policies.

DNS hostnames are names that are assigned to devices or services that serve as their network identity and are used to connect with them. An example of DNS hostname is cloud.ibm.com.

If you use a DNS hostname in policies, the local DNS name resolves the hostname to a single static IP address in the NPSaaS instance so that the policy can work effectively.

If the hostname resolves to multiple IP addresses or if the assigned IP addresses can change (for example, load balancer), make sure that you provide the CIDR range of those IP addresses in the policy rather than the DNS hostname.

Allowing connections only from a defined set of sources with the specified IP addresses and hostnames

If you want to allow connections to the NPSaaS database only from devices with IP addresses in the range that is represented by CIDR-1, CIDR-2, and hostnames H1 and H2, and reject connections from all other sources, follow these steps.

1. Create the policies in order from Rule 1 to Rule 5.

   Rule 1: CIDR-1    (allow)
   Rule 2: CIDR-2    (allow)
   Rule 3: H1        (allow)
   Rule 4: H2        (allow)
   Rule 5: 0.0.0.0/0 (deny)
   

   These rules ensure that connections are matched against Rule 1-4 to determine whether they can be allowed. If they are not allowed, Rule 5 rejects them.

   If someone is trying to connect to the NPSaaS database with hostnames H1 and H2, the database first tries to resolve the hostname to its IP address to complete the connection. Because the database might not have the DNS entry cached locally, the database tries to resolve the hostname by using a public DNS server. The DNS lookup fails because Rule 5 is in place. As a result, the connection attempt fails.

2. Add the public authoritative DNS server hostname or CIDR (DNS-1) to the allow rules for the DNS lookup to succeed.

   Rule 1: CIDR-1    (allow)
   Rule 2: CIDR-2    (allow)
   Rule 3: H1        (allow)
   Rule 4: H2        (allow)
   Rule 5: DNS-1     (allow)
   Rule 6: 0.0.0.0/0 (deny)
   

   The new rule is added as an allow rule (Rule 5).

Allowing connections only from on premises and take backups, load or unload data by using Cloud Object Store

If you want applications or users only from their on-premises network to connect to their NPSaaS database, follow these steps.

1. Use a public NAT gateway.

   The on-premises network is a private enterprise network, which uses a private IP address space. If the applications and users want to connect to services outside the on-premises network, they must use a public NAT gateway.

   The public NAT gateway has interfaces with public IP addresses in a range that is represented by CIDR-1 and replaces the source IP address of the instances in the enterprise network with one of the public IP address of the NAT gateway.

   As a result, external applications see all the traffic that comes from one of the public interfaces of the NAT gateway that is represented by CIDR-1.

2. Add CIDR-1 as an allow rule (Rule 1).

   Rule 1: CIDR-1    (allow)
   

3. Add a deny all rule (Rule 2) to restrict connections that originate only from the on-premises network.

   Rule 1: CIDR-1    (allow)
   Rule 2: 0.0.0.0/0 (deny)
   

4. Make connections from the database to the respective Cloud Object Store endpoints (such as AWS S3 and Azure Blob Storage).

   You must add endpoints to the allows list if you want your database admins to back up data to Cloud Object Store and developers to use external tables in applications to load and unload data.