Private Access to Oracle Services

• You can set up a VCN so that your on-premises network has private access to Oracle services in the Oracle Services Network by way of the VCN. The hosts in your on-premises network communicate with their private IP addresses.
• The VCN uses a dynamic routing gateway (DRG) to communicate with the on-premises network. Access to Oracle services is through a service gateway on the VCN. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the public internet.
• The service gateway is regional and enables access only to supported Oracle services in the same region as the VCN.
• The supported Oracle services are Oracle Cloud Infrastructure Object Storage and others in the Oracle Services Network. For a list, see Service Gateway: Supported Cloud Services in Oracle Services Network.
• The service gateway uses the concept of a service CIDR label, which is a string that represents all the regional public IP address ranges for the service or group of services of interest (for example, OCI PHX Object Storage is the string for Object Storage in US West (Phoenix)). You use that service CIDR label when you configure the service gateway and related route rules to control traffic to the service. You can optionally use it when configuring security rules. If the service's public IP addresses change in the future, you don't have to adjust those rules.
• To enable the intended traffic from the on-premises network through the VCN to Oracle services, you implement route rules for the VCN's DRG attachment and service gateway.
• If you want, you can set up transit routing through a private IP in the VCN. For example, you might want to filter or inspect the traffic between the on-premises network and the Oracle service. In that case, you route the traffic to a private IP on an instance in the VCN for inspection, and the resulting traffic continues to its destination. This topic covers both situations: transit routing directly between gateways on the VCN, and transit routing through a private IP.

The Oracle Services Network is a conceptual network in Oracle Cloud Infrastructure that is reserved for Oracle services. These services have public IP addresses that you typically reach over the public internet. However, you can access the Oracle Services Network without the traffic going over the public internet. There are different ways, depending on which of your hosts need the access:

• Hosts in your on-premises network:

  • Private access through a VCN with FastConnect private peering or Site-to-Site VPN: This scenario is covered in this topic. The on-premises hosts use private IP addresses and reach the Oracle Services Network by way of the VCN and the VCN's service gateway.
  • Public access with FastConnect public peering: The on-premises hosts use public IP addresses.
• Hosts in your VCN:
  • Private access through a service gateway: The VCN's hosts use private IP addresses.

The following diagram illustrates the basic layout for giving your on-premises network private access to Oracle services.

Your on-premises network connects to the VCN by way of a FastConnect private virtual circuit or Site-to-Site VPN. Each of these types of connections terminates on a Dynamic Routing Gateway (DRG) that is attached to the VCN. The VCN also has a service gateway, which gives the VCN access to the Oracle Services Network. The traffic from your on-premises network transits through the VCN, through the service gateway, and to the Oracle service of interest. The responses return through the service gateway and VCN to your on-premises network.

When you set up a service gateway, you enable a service CIDR label, which is a string that represents all the regional public IP address ranges for the service or group of services that you want to access through the service gateway. For example, All PHX Services in Oracle Services Network is the service CIDR label for the Oracle services available in US West (Phoenix) through a service gateway. Oracle uses Border Gateway Protocol (BGP) on the DRG to advertise those regional public IP address ranges to the edge device (also called the customer-premises equipment or CPE) in your on-premises network. For a list of those ranges available through the service gateway, see Public IP Addresses for VCNs and the Oracle Services Network.

Multiple VCNs with Private Access to Oracle Services

Your organization might choose to use multiple VCNs, each with a service gateway to give the VCN's resources access to Oracle services. For example, you might have a different VCN for each department in your organization.

If you also want to set up your on-premises network with private access to Oracle services through a VCN with a service gateway, this section describes two different network layouts you could use.

In the first layout, you set up a single DRG, with the VCNs in a hub-and-spoke layout as shown in the next diagram. The VCN that acts as the hub is dedicated to providing the on-premises network with private access to Oracle services. The other VCNs are locally peered with the hub VCN. You configure only the hub VCN according to instructions in Setting Up Private Access to Oracle Services. This hub-and-spoke layout is recommended and described further in Transit Routing inside a hub VCN.

In the second layout, there's a separate DRG for each VCN, with a separate FastConnect private virtual circuit or Site-to-Site VPN from your on-premises network to each DRG. You dedicate one DRG and VCN to providing your on-premises network with private access to Oracle services. In the next diagram, it's the VCN in the center. To configure that VCN, follow the instructions in Setting Up Private Access to Oracle Services.

Notice that in both of these layouts, the on-premises network can reach the Oracle services only through a single VCN's service gateway (the one dedicated for this purpose) and not through the service gateways of the other VCNs. For those other VCNs, only the resources inside those VCNs can reach Oracle services through their VCN's service gateway.

Regardless of which layout you choose, you can write an IAM policy to restrict access to an Object Storage bucket so that only requests that come through a specific VCN's service gateway are allowed for that bucket. With either of these layouts, you might want to write the policy to allow requests from multiple VCNs. To restrict access to specific VCNs, create a network source to specify the allowed VCN, and then write the policy restricting access to only the network source. One network source can specify multiple VCNs or you can create one network source for each VCN. For information on creating networks sources, see Managing Network Sources.

The following example policy assumes you set up one network source for each of your VCNs. The policy lets resources in the example ObjectBackup group write objects to an existing bucket called db-backup that resides in a compartment called ABC. When writing a policy like this one, you can specify one or more network sources. This example shows three.

Allow group ObjectBackup to read buckets in compartment ABC

Allow group ObjectBackup to manage objects in compartment ABC where
   all {target.bucket.name='db-backup', 
        any {request.networkSource.name='<hub_VCN_network_source>', request.networkSource.name='<spoke_1_VCN_network_source>', request.networkSource.name='<spoke_2_VCN_network_source>'},
        any {request.permission='OBJECT_CREATE', request.permission='OBJECT_INSPECT'}}

For more information, see Setting Up a Service Gateway in the Console in the procedure for setting up a service gateway.

Two options exist for routing through the VCN for private access to Oracle services:

• Transit routing directly through gateways: You route the traffic directly through the VCN, from one gateway to the other.
• Transit routing through a private IP: You set up an instance in the VCN to filter or inspect the traffic between the on-premises network and Oracle Services Network, and route traffic through a private IP on the instance.

The examples shown in the following sections assume that the VCN contains no workloads that need to access the on-premises network or Oracle Services Network. The VCN is being used only for transit routing of traffic through the VCN.

If you're a member of the Administrators group, you already have the required access to set up transit routing. Otherwise, you need access to the Networking service, and you need the ability to launch instances. See IAM Policies for Networking.

This section shows how to use the Console to set up transit routing with a VCN to give your on-premises network private access to Oracle services.

To turn off transit routing, remove the rules from:

• The route table associated with the DRG attachment.
• The route table associated with service gateway.

A route table can be associated with a resource but have no rules. Without at least one rule, a route table does nothing.

A DRG attachment or service gateway can exist without a route table associated with it. However, after you associate a route table with a DRG attachment or service gateway, there must always be a route table associated with it. But, you can associate a different route table. You can also edit the table's rules, or delete some or all rules.