Connectivity Patterns for Using Private OCI Object Storage with Cloudflare@OCI

Cloudflare@OCI brings OCI’s high-performance cloud together with Cloudflare’s global edge network to help secure and accelerate modern applications.

OCI Object Storage provides durable, scalable storage for unstructured data making it well suited for web assets, downloadable content, and application data. By using Object Storage as a Cloudflare origin, you can serve this content globally while maintaining controlled access to the bucket.

In this blog, we examine two secure patterns for using a fully private OCI Object Storage bucket as a Cloudflare origin. In both patterns, clients access content only through Cloudflare; they cannot access the bucket directly or produce a valid signed request without the credentials Cloudflare holds.

The following diagram provides a high-level view of each request path and the type of workload it supports. The sections that follow describe the implementation, security controls, and deployment considerations for each pattern.

Option 1 – Cloudflare Worker signs OCI

In this pattern, a Cloudflare Worker acts as the only authenticated client of the private OCI Object Storage bucket, which serves as the Cloudflare origin. The Worker authenticates to OCI using a dedicated OCI IAM user and that user’s API signing key, with read access limited to the target bucket. A visitor requests content through Cloudflare, where DNS, WAF, and cache controls are applied before the request reaches the Worker. On an edge-cache miss, the Worker validates the requested path, maps it to an approved OCI bucket and object prefix, and creates a signed HTTPS request to retrieve the object from OCI Object Storage. The response is returned through Cloudflare and can be in the local Cloudflare data center cache, while the bucket remains private and OCI credentials and direct bucket URLs are never exposed to the client.

Key controls

• Dedicated OCI service user: Use a non-human OCI IAM user with OBJECT_READ permission limited to the target bucket.
• Protected signing key: Store the user’s OCI API signing key only as an encrypted Cloudflare Worker secret; never expose it to clients or include it in source code.
• Strict request validation: Allow only GET and HEAD requests. Reject path traversal, ambiguous URL encoding, and any request that could select an unapproved bucket or object prefix.
• Safe edge caching: Use the Cloudflare Fetch API to cache eligible responses at the edge, while excluding OCI authentication and signing headers from the cache key.

Option 2 – OCI API Gateway and OCI Functions

In this pattern, Cloudflare forwards requests to OCI API Gateway, which invokes an OCI Function to retrieve content from the private OCI Object Storage bucket.

The Function uses an OCI resource principal instead of a stored API signing key, allowing OCI IAM to grant it controlled read access to the bucket. Before retrieving an object, the Function can apply entitlement checks, validate requests, transform or compose responses, and generate audit records.

Cloudflare continues to provide DNS, WAF, and edge caching, while the bucket remains private and clients never access it directly.

Deployment modes

Key Controls

• OCI resource principal: Configure the Function with a resource principal and a dynamic group policy granting OBJECT_READ access only to the target bucket. No Object Storage API key is stored or managed by the Function.
• Private bucket and least privilege: Keep the OCI Object Storage bucket private and scope IAM permissions to the required compartment, bucket, and read operations.
• Restricted API Gateway access: For a public API Gateway, restrict inbound traffic to Cloudflare where feasible and require appropriate gateway authentication or authorization. For a private API Gateway, deploy a Cloudflare Tunnel connector—typically on an OCI Compute VM or container workload with VCN access—to provide Cloudflare with private connectivity to the gateway.
• Private OCI networking: Run the Function in private networking and use an OCI Service Gateway or Private Service Access (PSA) to access Object Storage without exposing the Function or bucket to the public internet.
• Request and entitlement validation: Allow only required methods, such as GET and HEAD; validate paths and encoding; and enforce authorization before retrieving an object.
• Safe caching and responses: Cache only eligible responses at Cloudflare, exclude authorization-specific data from shared cache entries, and set appropriate cache-control and security headers.
• Auditing and monitoring: Enable API Gateway, Function, and Object Storage logging to record requests, access decisions, errors, and security-relevant events.

Performance, Scale, and Operational Considerations

Conclusion

Cloudflare@OCI brings Cloudflare’s global security, performance, and caching capabilities together with OCI cloud services, enabling organizations to deliver content from a fully private OCI Object Storage bucket without exposing the bucket, its objects, or OCI credentials directly to the internet.

Choose the Cloudflare Worker pattern for streamlined, cache-friendly object delivery, with Cloudflare acting as the authenticated OCI client. Choose the API Gateway and Functions pattern when OCI-native identity, private networking, advanced authorization, transformations, or audit processing are required.

The partnership also builds on Oracle and Cloudflare’s participation in the Bandwidth Alliance. Eligible data transfer from OCI Object Storage to Cloudflare can receive zero-egress pricing in supported regions. This helps make secure, globally distributed content delivery from OCI more predictable and cost-efficient. Oracle’s Cloudflare@OCI announcement

Nelson Espinal Principal Partner Architect Cloudflare