Release Notes

Service gateway with private access to Object Storage from a VCN

  • Services: Networking
  • Release Date: June 12, 2018
  • API Versions Affected: 20160918

The resources in your VCN can now use a service gateway to access Object Storage over a private connection that does not traverse the internet.

Your DB systems that use Object Storage for backup and patching no longer need to be in a public subnet with access to an internet gateway. Instead, they can be in a private subnet with access to a service gateway.

Important: See this known issue for information about accessing Yum services through the service gateway.

For more information about service gateways, see Access to Object Storage: Service Gateway.

Possible Breaking API Changes If Your Organization Uses a Service Gateway

Important: This is applicable ONLY if you or other users with appropriate access in your organization use a service gateway with a VCN. If this is not the case, you are not affected.

If your organization uses a service gateway with a VCN, you must update the code for all your clients that work with the Networking service route rules and security lists. The APIs for these resources have changed as part of the service gateway release. See the following details.

Changes to Route Tables

Summary: The RouteRule object has changed: its cidrBlock attribute has been deprecated in favor of two new attributes: destinationType and destination. When destinationType has a value other than CIDR_BLOCK, the value of cidrBlock may now be null. If your code assumes that cidrBlock is not null, it may fail during runtime or not generate the expected outcome. 

RouteRule Changes

Before the change, the RouteRule object had these attributes:

  • cidrBlock: Value is the CIDR block for the rule (for example, 10.0.1.0/24).
  • networkEntityId: Value is the OCID of the target (for example, an internet gateway or dynamic routing gateway).

A route rule consisted of a CIDR block to match traffic to, and the target.

Now, the RouteRule object has these attributes:

  • cidrBlock: DEPRECATED in favor of destinationType and destination. Note: The value can now be null (see the discussion that follows).
  • destinationType (enum):
    • CIDR_BLOCK
    • SERVICE_CIDR_BLOCK
  • destination
    • If destinationType=CIDR_BLOCK, the value is a string representation of the CIDR block for the rule (for example, 10.0.1.0/24).
    • If destinationType=SERVICE_CIDR_BLOCK, the value is a string that identifies a particular service's public CIDR block. See the cidrBlock attribute of the Service object. Example: oci_phx_objectstorage.
  • networkEntityId: No change.

For existing rules that use the deprecated cidrBlock:

  • Setting destinationType=CIDR_BLOCK and destination=<CIDR block> is equivalent to existing route rules that use the old cidrBlock attribute. However, if your code provides only the deprecated cidrBlock attribute in a request object, the value will be honored and included in the RouteRule object. The object's cidrBlock will contain your value and not be null. The destinationType and destination will be set accordingly: the destinationType will be set to CIDR_BLOCK, and the destination will be set to the same value as cidrBlock.
  • If your code sets both cidrBlock and destination with destinationType, and the values are consistent, the resulting RouteRule object will have all the values set accordingly. However, if the values conflict, the service will return an error and does not apply your requested change.

For a new rule to route to a service gateway:

  • A route rule for a service gateway has destinationType=SERVICE_CIDR_BLOCK and destination=<string>. The deprecated cidrBlock attribute will be null. If your code assumes the attribute cannot be null, the code may fail during runtime or not generate the expected outcome.

Changes to Security Lists

Summary: The EgressSecurityRule and IngressSecurityRule objects have changed. The definition of the destination attribute in the EgressSecurityRule object has been relaxed, and a new destinationType attribute has been added. If your code assumes the value of the destination field will be a string representation of a CIDR block (for example 10.0.1.0/24), the code may fail during runtime or not generate the expected outcome.

Similarly for ingress rules: The definition of the source attribute in the IngressSecurityRule object has been relaxed, and a new sourceType attribute has been added. If your code assumes the value of the source field will be a string representation of a CIDR block, the code may fail during runtime or not generate the expected outcome.

EgressSecurityRule Changes

Before the change, the EgressSecurityRule had these attributes:

  • destination: The destination CIDR block for the egress rule (for example: 10.0.1.0/24)
  • Plus some others not relevant here

After the change:

  • destinationType (enum):
    • CIDR_BLOCK
    • SERVICE_CIDR_BLOCK
  • destination: The definition of this existing field has relaxed to allow two different kinds of values.
    • If destinationType=CIDR_BLOCK, the value is a string representation of the destination CIDR block for the egress rule (for example, 10.0.1.0/24).
    • If destinationType=SERVICE_CIDR_BLOCK, the value is a string that identifies a particular service's public CIDR block. See the cidrBlock attribute of the Service object. Example: oci_phx_objectstorage.
  • Plus some others not relevant here

In any request objects, your code should populate the destinationType. Otherwise, the Networking service defaults the value to CIDR_BLOCK.

When reading an EgressSecurityRule, your code should check the destinationType first before parsing the value of the destination attribute. If your code assumes the value of the destination field will be a string representation of a CIDR block (for example 10.0.1.0/24), the code may fail during runtime or not generate the expected outcome.

IngressSecurityRule Changes

The changes are similar to EgressSecurityRule, except they involve source and sourceType instead of destination and destinationType. If your code assumes the value of the source field will be a string representation of a CIDR block, the code may fail during runtime or not generate the expected outcome.