X

Getting Up to Speed on Using Private Endpoints for Autonomous Database with Shared Exadata Infrastructure

Rajeev Ranjan
Principal Product Manager

Oracle Autonomous Database is built on the foundation of Oracle Cloud Infrastructure, a cloud platform committed to providing the highest possible security standards to enterprises. Because network security is a critical aspect of cloud security, we recently launched the ability to create a private endpoint to your Autonomous Database (on shared Exadata infrastructure) in your virtual cloud network (VCN). With a private endpoint, database traffic remains private and within Oracle Cloud Infrastructure.

In this post, I discuss some use cases and walk you through the steps for provisioning and connecting to an Autonomous Database with a private endpoint.

Why Should You Use a Private Endpoint?

Before this launch, Autonomous Databases on shared Exadata infrastructure used only a public endpoint, which can be a problem if your organization prohibits the use of a public endpoint for databases. When you enable a private endpoint for an Autonomous Database, the only access path to the database is through a VCN inside your Oracle Cloud Infrastructure tenancy. The private endpoint completely blocks access to the database from public endpoints.

A private endpoint also simplifies the connection from an on-premises database through a private network. You don't have to set up transit routing in your VCN and use a service gateway to connect to your database.

Creating an Autonomous Database with a Private Endpoint

Creating an Autonomous Database with a private endpoint is a straightforward process. Before you do that, though, you need to have the following networking resources in place:

  • A virtual cloud network (VCN) in the region where you want to create the Autonomous Database. In the VCN subnet, select Default DHCP Options (this choice sets up an internet resolver and a VCN resolver).
  • At least one subnet in the VCN.
  • At least one network security group (NSG) in the VCN.

With these networking prerequisites in place, you can create an Autonomous Database to use a private endpoint in your VCN.

In the Create Autonomous Database workflow in the Oracle Cloud Infrastructure Console, select the Virtual cloud network option for network access.

Screenshot that shows the Create Autonomous Database workflow in the Console, with the Virtual cloud network option selected for network access.

You’re then prompted to specify a VCN, a subnet, an optional hostname prefix, and at least one NSG. The optional hostname prefix is used to create a unique DNS name (fully qualified domain name, or FQDN) for your database. If you don't provide a hostname prefix, the Autonomous Database service generates a unique DNS name for you. The FQDN gets resolved to the private IP address of the database in the VCN.

After the database is provisioned, you can see the networking details on the Autonomous Database Details page.

Screenshot of the Autonomous Database Details page in the Console, showing networking details.

You can also use the Oracle Cloud Infrastructure API, CLI, and Terraform to create your Autonomous Database (on shared Exadata infrastructure) with a private endpoint.

Enabling a Private Endpoint in an Existing Database

If you want to use a private endpoint with an existing database that currently uses a public endpoint, you clone the database and select the Virtual cloud network option for network access during the clone provisioning process. If your source database has an access control list (ACL) that specifies allowed IP addresses and VCNs, the ACL won’t be a part of your cloned database. Instead of using an ACL, you define security rules within your network security group (or groups) to control traffic to and from your target database with a private endpoint.

Connecting to an Autonomous Database with a Private Endpoint

You can connect to the database from a VCN or from your on-premises data center.

Scenario 1: Connecting from Your VCN

This method is useful if you have an application that is running inside Oracle Cloud Infrastructure, either on a virtual machine (VM) in the same VCN that is configured with your database or on a VM in a different VCN.

The following network diagram shows an application running in the same VCN as the database. The Autonomous Data Warehouse (ADW) instance has a private endpoint in VCN A and subnet A (CIDR 10.0.2.0/24). The NSG associated with the Autonomous Data Warehouse instance is NSG 1. The application that connects to the Autonomous Data Warehouse instance is running on a VM that is in subnet B (CIDR 10.0.1.0/24).

Network diagram that shows an application running in the same VCN as the database.

To allow incoming and outgoing traffic to the Autonomous Data Warehouse instance, you need to define security rules in NSG 1. Because private endpoint security rules have to be stateless, you have to create both ingress and egress rules for the Autonomous Data Warehouse instance. For information about setting up security rules, see the network security groups documentation.

Here's an example pair of security rules that function together to control ingress and egress traffic.

Screenshot that shows security rules that allow ingress traffic from the source 10.0.1.0/24 (the CIDR for subnet B, where the application runs) on the destination port range 1522, and egress traffic from the ADW instance to the destination 10.0.1.0/24.

These rules allow ingress traffic from the source 10.0.1.0/24 (the CIDR for subnet B, where the application runs) on the destination port range 1522, and egress traffic from the ADW instance to the destination 10.0.1.0/24.

You also need to create a security rule to allow traffic to and from the VM. You can use a stateful security rule for the VM, so defining a rule for egress to the destination subnet (10.0.2.0/24) is enough.

Screenshot that shows a security rule that allows egress traffic to the destination subnet (10.0.2.0/24).

After you configure the security rules, your application can connect to the Autonomous Data Warehouse database by using the database wallet, just as you would usually connect.

To connect from an application running in a different VCN, you would have to set up VCN peering and security rules accordingly. For details, read this excellent blog post about VCN peering.

Scenario 2: Connecting from Your Data Center

This method is useful if you want to connect privately to an Autonomous Database from your on-premises data center. In this scenario, traffic never goes over the public internet. To connect from your data center, you need to connect the on-premises network to the VCN with FastConnect and then set up a dynamic routing gateway (DRG). Resolving the database’s private endpoint (FQDN) requires you to add an entry in your on-premises host’s /etc/hosts file with the database’s private IP address and FQDN (example entry: 10.0.3.14  petestadw.adb.ca-toronto-1oraclecloud.com). You can find the private IP address on the database details page and the FQDN in tnsnames.ora inside your wallet. Alternatively, you can set up hybrid DNS in Oracle Cloud Infrastructure for DNS name resolution.

The following network diagram shows a DRG set up between an on-premises data center and VCN A, which also contains the Autonomous Data Warehouse (ADW) database. A route table in the subnet is associated with the database for outgoing traffic to CIDR 172.16.0.0/16 via the DRG.

Network diagram that shows a DRG set up between an on-premises data center and a VCN, which also contains the database. A route table in the subnet is associated with the database for outgoing traffic to CIDR 172.16.0.0/16 via the DRG.

Traffic is also allowed to and from the database by means of two stateless security rules (for ingress and egress) for the data center CIDR range (172.16.0.0/16).

Screenshot that shows two stateless security rules (for database ingress and egress) for the data center CIDR range (172.16.0.0/16).

After the security rules are configured appropriately, the application should be able to connect to the Autonomous Data Warehouse database by using the wallet.

And That's It!

Oracle Autonomous Database, a fully managed and highly secure cloud database, supports both public and private network access models. You decide which network model you need, based on your organization's requirements. In this post, I discussed the use case for a private endpoint, and the steps required to set up and connect to (via your VCN) an Autonomous Database that uses a private endpoint. If you need information about the public endpoint access model for Autonomous Database with shared Exadata infrastructure, see the blog post and documentation about this option.

You can find more documentation at the following links:

Join the discussion

Comments ( 2 )
  • Masthan Thursday, February 27, 2020
    Nice and very detailed post and it helps, thank you.
  • Rajeev Tuesday, April 28, 2020
    We now support stateful security rules for private endpoint, which means you don't have to create both ingress and egress rules for the Autonomous Data Warehouse instance.

    An NSG for the Autonomous Database can have either stateful or stateless security rules.Check details at https://docs.cloud.oracle.com/en-us/iaas/Content/Database/Concepts/adbsprivateaccess.htm
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.