Oracle Cloud Infrastructure Documentation

Access to Object Storage: Service Gateway

This topic describes how to set up and manage a An optional virtual router that you can add to your VCN to provide a path for private network traffic between your VCN and a public Oracle Cloud Instrastructure service such as Object Storage. to give cloud resources without public IP addresses private access to public Oracle Cloud Infrastructure 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.

Highlights

  • A service gateway enables your VCN to access public Oracle Cloud Infrastructure services such as Object Storage, but without exposing the VCN to the public internet. No internet gateway is required. The resources in the VCN can be in a private subnet and use only private IP addresses.
  • The traffic from the VCN to the regional Object Storage travels over the Oracle Cloud Infrastructure network fabric and never traverses the internet.
  • The service gateway is regional and enables access only to supported services in the same region as the VCN.
  • If you're using a service gateway, you can protect an Object Storage bucket by allowing only requests from an authorized VCN or CIDR block.

Overview

A service gateway lets resources in your virtual cloud network (VCN) access public Oracle Cloud Infrastructure services such as Object Storage, but without using an internet gateway or NAT. Any traffic from your VCN that is destined for one of the supported public services uses the instance's private IP address for routing, travels over the Oracle Cloud Infrastructure network fabric, and never traverses the internet.

The following diagram illustrates a VCN with a service gateway. In this case, the VCN has both a public subnet and a private subnet. The route table for the public subnet sends non-local traffic through the internet gateway. The route table for the private subnet sends non-local traffic through the service gateway to Object Storage. Resources in the private subnet have only private IP addresses and cannot communicate with the internet.

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

Example: You want to back up DB Systems in your VCN to Object Storage, which has public endpoints. Without the service gateway, your VCN must have an internet gateway. The DB Systems must have public IP addresses and be in a public subnet with access to the internet gateway. Or you must set up NAT in your VCN. With a service gateway, no internet gateway is required on your VCN for DB System backup. The DB Systems can be in a private subnet and have only private IP addresses. The backup traffic is routed through the service gateway. You can set up IAM policies that restrict access to the bucket from only the VCN or the private subnet within the VCN.

Important

If you want to place DB Systems in a private subnet and use a service gateway to access Object Storage, see Known Issues for information about OS updates when using a service gateway.

You control routing in your VCN at the subnet level, so you can specify which subnets in your VCN use a service gateway. You can also configure which of the supported public Oracle Cloud Infrastructure services are accessible through the service gateway. For example, one subnet could use a service gateway to access service ABC, and another subnet could use a different service gateway to access service XYZ.

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, you can use FastConnect public peering if your on-premises resources need access to Object Storage without the traffic traversing the internet.

For information about the number of service gateways you can have, see Service Limits.

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

Services Available with a Service Gateway

Object Storage is the first service to be available with a service gateway.

In general, when you add a service gateway to your VCN, you can specify which service or services you want to enable with the gateway. The Console shows the list of available services to choose from. If you're using the REST API, use the ListServices operation to get the list of services. At any time, you can change which ones are enabled for the service gateway. Make sure that you have corresponding route rules and security list rules for the service (covered in the following sections).

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 automatically always attached to only one VCN of your choice. 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 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. You don't have to know the specific CIDR blocks for the service's public endpoints, which could change over time. Instead, in the Console, you simply specify the service you want to access (for example, Object Storage). If you're using the API, you specify an Oracle-defined string that represents the service's endpoints. For example: oci-phx-objectstorage. The ListServices operation returns that string.

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

For traffic to be allowed in or out of instances in the subnet, you must also have rules for that traffic in the subnet's security list. As with route rules, when setting up security list rules for a service gateway in the Console, you can simply specify the service instead of a source CIDR or destination CIDR for the rule. If you're using the API, you specify the Oracle-defined string that represents the service's endpoints.

You can use stateful or stateless rules:

  • For stateful rules: Create an egress rule with the destination service = the service 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 of interest. Also create an ingress rule with the source service = the service 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 for a service gateway, see Task 3: (Optional) Update the security lists for the subnet.

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.

Allowing Access from Only a Particular VCN or CIDR Range

If you like, you can write an IAM policy that allows access to a particular Object Storage bucket only if the request originates from a particular VCN or CIDR range (for example, a subnet within a VCN) and goes through a service gateway.

For examples of IAM policies and important caveats about using the policies, see Task 4: (Optional) Update IAM Policies.

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 for Managing Service Gateways

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.

Tagging Resources

You can apply tags to your resources to help you organize them according to your business needs. For general information about applying tags, see Resource Tags.

Setting Up a Service Gateway

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

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

Using the Console

To block or allow traffic for a service gateway
To update a service gateway
To add or remove a service from a service gateway
To delete a service gateway
To manage tags for a service gateway

Using 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.