Controlling Access to Invoke and Manage Functions

When configuring a tenancy for function development, you specify the following identity policy statement (as described in Policy Statements to Give Oracle Functions Users Access to Function-Related Resources):

Allow group <group-name> to manage functions-family in compartment <compartment-name>

This identity policy enables authenticated users in the specified group to manage (that is, create, update, and delete) functions and applications in the named compartment, and also enables those users to invoke functions in the compartment. This policy typically meets the requirements of functions developers developing and testing multiple functions in your organization.

However, this identity policy might be too permissive to meet your security requirements to control the invocation and management of functions in production environments. For example, in a production environment you might want to prevent users from invoking functions completely, or restrict users to invoking just functions in a specific application, or to invoking just a particular function.

Note

Specifying a private subnet for an application does not prevent access from the internet to the invoke endpoints of functions in the application. Use identity policies to control access to function invoke endpoints, as described in this topic.

To control the functions that users in a group can invoke and manage, set up identity policies:

  1. To control the functions that a user can invoke and manage, confirm that they are not in a group that has been given the manage functions-family permission.

  2. If you want to enable users in a group to create, update, and delete applications and functions in a compartment, but to be unable to invoke functions, enter the following policy statements:
    Allow group <group-name> to manage fn-app in compartment <compartment-name>
    Allow group <group-name> to manage fn-function in compartment <compartment-name>
  3. If you want to allow invocations of particular functions only, or invocations of functions in particular applications only, include the appropriate function and application OCIDs in suitable policy statements. For example:

    • To enable users to invoke all the functions in a specific application, enter a policy statement in the following format:
      Allow group <group-name> to use fn-invocation in compartment <compartment-name> where target.app.id = '<application-OCID>'
    • To enable users to invoke one specific function, enter a policy statement in the following format:
      Allow group <group-name> to use fn-invocation in compartment <compartment-name> where target.function.id = '<function-OCID>'
    • To enable users to invoke all the functions in all applications except for functions in one specific application, enter a policy statement in the following format:
      Allow group <group-name> to use fn-invocation in compartment <compartment-name> where target.app.id != '<application-OCID>'
    • To enable users to invoke all the functions in a compartment except for one specific function, enter a policy statement in the following format:
      Allow group <group-name> to use fn-invocation in compartment <compartment-name> where target.function.id != '<function-OCID>'
    • To enable users to invoke two specific functions, enter a policy statement in the following format:
      Allow group <group-name> to use fn-invocation in compartment <compartment-name> where ANY {target.function.id='<function-OCID>', target.function.id='<function-OCID>'}
    • To enable users to invoke one specific function along with all the functions in a specific application, a policy statement in the following format:
      Allow group <group-name> to use fn-invocation in compartment <compartment-name> where ANY {target.function.id='<function-OCID>', target.app.id='<application-OCID>'}
  4. If you want to allow function invocation and management requests only from particular IP addresses:

    1. Create a network source to specify the allowed IP addresses, if a suitable network source doesn't exist already (see Managing Network Sources).
    2. Add a policy statement to enable only those IP addresses in the network source to invoke or manage functions. For example:

      • To only allow function invocation requests from IP addresses defined in a network source named corpnet, enter a policy statement in the following format:

        Allow group <group-name> to use fn-invocation in compartment <compartment-name> where request.networkSource.name='corpnet'
      • To only allow function management requests from IP addresses defined in a network source named corpnet, enter a policy statement in the following format:

        Allow group <group-name> to manage functions-family in compartment <compartment-name> where request.networkSource.name='corpnet'