Oracle Cloud Infrastructure Documentation

Access to Oracle Services: Service Gateway

This topic describes how to set up and manage a service gateway. A service gateway enables cloud resources without public IP addresses to privately access Oracle services.

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.

Access to Oracle Services

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 can be reached over the internet. However, you can access the Oracle Services Network public IP addresses without the traffic going over the internet. There are different ways, depending on which of your hosts need the access:

Highlights

  • A service gateway lets your virtual cloud network (VCN) privately access specific Oracle services without exposing the data to the public internet. No internet gateway or NAT is required to reach those specific services. The resources in the VCN can be in a private subnet and use only private IP addresses. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet.
  • The service gateway is regional and enables access only to supported Oracle services in the same region as the VCN.
  • The service gateway allows access to supported Oracle services within the region to protect your data from the internet. Your workloads may require access to public endpoints or services not supported by the service gateway (for example, to download updates or patches). Ensure you have a NAT gateway or other access to the internet if necessary.

  • 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-phoenix-1). 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 list rules. If the service's public IP addresses change in the future, you don't have to adjust those rules.

Overview of Service Gateways

A service gateway lets resources in your VCN privately access specific Oracle services, without exposing the data to an internet gateway or NAT. The resources in the VCN can be in a private subnet and use only private IP addresses. The traffic from the VCN to the service of interest travels over the Oracle network fabric and never traverses the internet.

The following simple diagram illustrates a VCN that has both a A subnet in which instances are allowed to have public IP addresses. When you launch an instance in a public subnet, you specify whether the instance should have a public IP address. and a A subnet in which instances are not allowed to have public IP addresses. Resources in the private subnet have only private IP addresses.

The VCN has three gateways:

  • Internet gateway: To provide the public subnet direct access to public endpoints on the internet. Connections can be initiated from the subnet or from the internet. The resources in the public subnet must have public IP addresses. For more information, see Internet Gateway.
  • Service gateway: To provide the private subnet with private access to supported Oracle services within the region. Connections can be initiated only from the subnet.
  • NAT gateway: To provide the private subnet with private access to public endpoints on the internet. Connections can be initiated only from the subnet. For more information, see NAT Gateway.

You control routing in your VCN at the subnet level, so you can specify which subnets in your VCN use each gateway. In the diagram, the route table for the public subnet sends non-local traffic through the internet gateway. The route table for the private subnet sends traffic destined for the Oracle services through the service gateway. It sends all remaining traffic to the NAT gateway.

This image shows the basic layout of a VCN with a service gateway

A service gateway can be used only by resources in the gateway's own VCN. If the VCN is peered with another, resources in the other VCN cannot access the service gateway. Also, resources in an on-premises network connected to the service gateway's VCN with FastConnect or an IPSec VPN cannot use the service gateway. However, the on-premises network can use FastConnect public peering for private access to public Oracle Cloud Infrastructure services. For a list of services available with FastConnect public peering, see FastConnect Supported Cloud Services.

A VCN can have only one service gateway. For more information about limits, see Service Limits.

For instructions on setting up a service gateway, see Setting Up a Service Gateway in the Console.

About Service CIDR Labels

Each Oracle service has a regional public endpoint that uses public IP addresses for access. When you set up a service gateway with access to an Oracle service, you also set up Networking service route rules and optionally security list rules that control traffic with the service. That means you need to know the service's public IP addresses to set up those rules. To make it easier for you, the Networking service uses service CIDR labels to represent all the public CIDRs for a given Oracle service or a group of Oracle services. If a service's CIDRs change in the future, you don't have to adjust your route rules or security list rules.

Examples:

  • OCI PHX Object Storage is a service CIDR label that represents all the Object Storage CIDRs in the us-phoenix-1 region.
  • All PHX Services in Oracle Services Network is a service CIDR label that represents all the CIDRs for the supported services in the Oracle Services Network in the us-phoenix-1 region. For a list of the services, see Service Gateway: Supported Cloud Services in Oracle Services Network.

As you can see, a service CIDR label can be associated with either a single Oracle service (example: Object Storage), or multiple Oracle services.

The term service is often used in this topic in place of the more accurate term service CIDR label. The important thing to remember is that when you set up a service gateway (and related route rules), you specify the service CIDR label you're interested in. In the Console, you're presented with the available service CIDR labels. If you use the REST API, the ListServices operation returns the available Service objects. The Service object's cidrBlock attribute contains the service CIDR label (example: all-phx-services-in-oracle-services-network).

Available Service CIDR Labels

Here are the available service CIDR labels:

Important

See this known issue for information about accessing Oracle YUM services through the service gateway.

Enabling a Service CIDR Label for a Service Gateway

To give your VCN access to a given service CIDR label, you must enable that service CIDR label for the VCN's service gateway. You can do that when you create the service gateway, or later after it's created. You can also disable a service CIDR label for the service gateway at any time.

Important

Because Object Storage is covered by both OCI <region> Object Storage and All <region> Services in Oracle Services Network, a service gateway can use only one of those service CIDR labels.

Likewise, a route table can have a single rule for one of the service CIDR labels. It cannot have two separate rules, one for each label.

Also, the Console enforces a special restriction: when you set up a route rule that uses a service gateway as the target, the rule's destination service must be the service CIDR label that is enabled for that service gateway.

If you want to switch the service gateway to use a different service CIDR label, see To switch to a different service CIDR label.

Blocking Traffic Through a Service Gateway

You create a service gateway in the context of a specific VCN. In other words, the service gateway is always attached to that one VCN. However, you can block or allow traffic through the service gateway at any time. By default, the gateway allows traffic flow upon creation. Blocking the service gateway traffic prevents all traffic from flowing, regardless of what service CIDR labels are enabled, or any existing route rules or security lists in your VCN. For instructions on how to block traffic, see To block or allow traffic for a service gateway.

Route Rules and Security List Rules for a Service Gateway

For traffic to be routed from a subnet in your VCN to a service gateway, you must add a rule accordingly to the subnet's route table. The rule must use the service gateway as the target. For the destination, you must use the service CIDR label that is enabled for the service gateway. This means that you don't have to know the specific public CIDRs, which could change over time.

Any traffic leaving the subnet and destined for the service's public CIDRs is then routed to the service gateway. If the service gateway traffic is blocked, no traffic flows through it even if there's a route rule that matches the traffic. For instructions on setting up route rules for a service gateway, see Task 2: Update routing for the subnet.

The subnet's security lists must also allow the desired traffic. If you like, you can use a service CIDR label instead of a CIDR for the source or destination of the desired traffic. Again, this means that you don't have to know the specific public CIDRs for the service. For convenience, you can use a service CIDR label in security list rules even if your VCN doesn't have a service gateway, and the traffic to the services uses an internet gateway.

You can use stateful or stateless security list rules that use a service CIDR label:

  • For stateful rules: Create an egress rule with the destination service = the service CIDR label of interest. As with any security list rule, you can specify other items such as the IP protocol and source and destination ports.
  • For stateless rules: You must have both egress and ingress rules. Create an egress rule with the destination service = the service CIDR label of interest. Also create an ingress rule with the source service = the service CIDR label of interest. As with any security list rule, you can specify other items such as the IP protocol and source and destination ports.

For instructions on setting up security list rules that use a service CIDR label, see Task 3: (Optional) Update the security lists for the subnet.

Object Storage: Allowing Bucket Access from Only a Particular VCN or CIDR Range

If you use a service gateway to access Object Storage, you can write an IAM policy that allows access to a particular Object Storage bucket only if these requirements are met:

  • The request goes through a service gateway.
  • The request originates from the particular VCN or CIDR (for example, a subnet within a VCN) that is specified in the policy.

For examples of this particular type of IAM policy, and important caveats about its use, see Task 4: (Optional) Update IAM Policies to Restrict Object Storage Bucket Access.

Deleting a Service Gateway

To delete a service gateway, its traffic does not have to be blocked, but there must not be a route table that lists it as a target. See To delete a service gateway.

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: see IAM Policies for Networking.

Setting Up a Service Gateway in the Console

Following is the process for setting up a service gateway. It assumes that you already have a VCN with a subnet (either private or public).

Important

The service gateway allows access to supported Oracle services within the region to protect your data from the internet. Your applications may require access to public endpoints or services not supported by the service gateway (for example, to download updates or patches). Ensure you have a NAT gateway or other access to the internet if necessary.

Task 1: Create the service gateway
Task 2: Update routing for the subnet
Task 3: (Optional) Update the security lists for the subnet
Task 4: (Optional) Update IAM Policies to Restrict Object Storage Bucket Access

Managing a Service Gateway in the Console

To switch to a different service CIDR label
To update a service gateway
To block or allow traffic for a service gateway
To delete a service gateway
To manage tags for a service gateway

Managing a Service Gateway with 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.

Warning

If anyone in your organization implements a service gateway, be aware that you may need to update any client code that works with Networking service route rules and security lists. There are possible breaking API changes. For more information, see the service gateway release notes.

To manage your service gateways, use these operations:

To manage route tables, see Route Tables. To manage security lists, see Security Lists. To manage IAM policies, see Managing Policies.