Oracle Cloud Serverless Functions unleashed: exposing OCI Functions through API Gateway

Lucas Jellema

Oracle Cloud Infrastructure API Gateway makes it possible to expose OCI Functions on public endpoints that do not require complex signed HTTP requests. Any function that should be easily publicly accessible can be given such easy access. By creating an API Deployment on an API Gateway and associating a route in that API Deployment with an Oracle Function Backend. If needed, parameter mapping can be added as well as custom authorization and CORS headers in addition to rate limiting, monitoring and logging.

This article describes how easy it is to take a prepared Oracle Function (see for example this article) and a an existing API Gateway (check out this article for an introduction) and add the required security configuration and the route definition to expose the Oracle Function publicly. Once that has been done, these Functions are unleashed. They can be wired together easily, engaged from just about anywhere and start playing the role I believe they are meant to play.

image

The steps required (provided an API Gateway instance exists and a Function has been deployed) are straightforward:

  • create dynamic group with matching rule (that ensures that the API Gateway is a member of the dynamic group)
  • create a policy with three statements (that grant privileges to the dynamic group)
  • create an API deployment and a route with Oracle Function as backend type; select the target Function
  • optional: add additional log and request policies on the API deployment or the routes
  • invoke the Function through the new public endpoint on the API Gateway (once all changes have been processed)

Assuming the function has been deployed and can be invoked (in this case function hello in application lab-app in compartments functions-compartment), we can get going:

image

image

    Create dynamic group with matching rule (that ensures that the API Gateway is a member of the dynamic group)

    The API Gateway needs to have permission to access the Function that we want to include in the API Deployment’s Route as a backend. The suggested way for realizing this is through the definition of a Dynamic Group. Dynamic groups allow you to group Oracle Cloud Infrastructure resources as “principal” actors (similar to user groups). You can then create policies to permit instances to make API calls against Oracle Cloud Infrastructure services. When you create a dynamic group, rather than adding members explicitly to the group, you instead define a set of matching rules to define the group members. See the documentation here.

    Here I have defined the Dynamic Group fn-gw-dynamic-group.

    The intended matching rule is composed of two conditions: resource.type equals ApiGateway and resource.compartment.id equal the OCID of the compartment where the API Gateway was created (the functions-compartment). The resulting rule:

    ALL {resource.type = ‘ApiGateway’, resource.compartment.id = ‘ocid1.compartment.oc1..aaaaaaaatxf2nfi7pnoyq4ilq’}

    Initially, however, with this Matching Rule in place, the API Gateway was not able to access the Function. When I changed ALL to ANY, the access was available. I tried to find out which part of the rule was matched and which was not. Both seemed to be. I then changed ANY back to AND. And the access was still there. I am not sure if I did something wrong (typo in the rule?) or there was a timing issue. Anyways, now it is working as expected.

    image

    Create a policy with three statements (that grant privileges to the dynamic group)

    The Dynamic Group needs permissions. All members of the group – i.e. the API Gateway – needs three permissions in order to successfully invoke any Function in functions-compartment. These permissions are provided through a policy. The following policy is created in the functions-compartment: dyn-group-gateway-access-functions-compartment and three statements are added:

    • allow dynamic-group [your dynamic group] to use virtual-network-family in compartment [compartment name]
    • allow dynamic-group [your dynamic group] to manage public-ips in compartment [compartment name]
    • allow dynamic-group [your dynamic group] to use functions-family in compartment [compartment name]

    image

    With these three statements, the dynamic group receives all the permissions it needs.

    image

    Create an API deployment and a route with Oracle Function as backend type; select the target Function

    Select the API Gateway that will contain the API Deployment exposing the Function.

    Click on Create Deployment:

    image

    Configure the basic configuration: the name fn, the path prefix /fn and the compartments functions-compartment (in my situation):

    image

    Press Next.

    Configure the Route leading to Function hello. Here is the configuration for Route 1: the path is /hello (so on top of the API Deployment’s path this makes /fn/hello), the supported methods are GET and POST. The backend type is Oracle Functions and the target Function to be invoked is Function hello compartment lap-app.

    image

    optional: add additional log and request policies on the API deployment or the routes.

    Click on Next. Click on Create:

    image

    The new API Deployment is in the process of being created:

    image

    and after a little while, the API Deployment is ready for action:

    image

    Invoke the Function through the new public endpoint on the API Gateway (once all changes have been processed)

      A call to the API on the API Gateway can easily be made from for example Postman. API Gateway will then invoke the Function and the response from the function is returned to the client:

      image

      Here we see a POST request sending a simple JSON payload and a response that makes clear that the payload has been received and processed.

      From the command line using Curl:

      curl -X POST \
         https://ohv2pohmm.apigateway.us-ashburn-1.oci.customer-oci.com/fn/hello \
         -d ‘{
      “name”:”John Dimbleby”,
      “payload”:{“param1″:”221”, “param2″:”Some Payload value”}
      }’

      image

      Resources

      My previous blog article: Introducing Oracle Cloud API Gateway – the light weight public or private router to public and private OCI endpoints – https://technology.amis.nl/2019/12/23/first-steps-with-oracle-cloud-api-gateway-the-light-weight-public-or-private-router-to-public-and-private-oci-endpoints/

      First steps with API Gateway – https://technology.amis.nl/2019/12/23/my-first-steps-with-oracle-cloud-api-gateway-the-stock-response/ 

      OCI API Gateway Docs – Adding a Function in Oracle Functions as an API Gateway Back End – https://docs.cloud.oracle.com/iaas/Content/APIGateway/Tasks/apigatewayusingfunctionsbackend.htm

      Article/Tutorial by Todd Sharp – Creating Your First API Gateway In The Oracle Cloud – https://blogs.oracle.com/developers/creating-your-first-api-gateway-in-the-oracle-cloud


      Leave a Reply

      This site uses Akismet to reduce spam. Learn how your comment data is processed.

      Next Post

      Oracle Cloud Infrastructure Functions and Project Fn - Retrieving Headers, Query Parameters and other HTTP Request elements

      Facebook0TwitterLinkedinFunctions on Oracle Cloud Infrastructure are implemented using Project Fn. A function runs in Docker container. This container has a runtime (for example for Java, Go, Python, Node) and a minimal handler to handle an HTTP request and turn it into a call to the function. When writing the code […]