Creating Policies to Control Access to Network and Function-Related Resources

When OCI Functions users work with functions, they have to access repositories in Oracle Cloud Infrastructure Registry. Users can only access repositories that the groups to which they belong have been granted access. To enable users to access a repository, policy statements must grant the groups access to that repository.

The policy statement Allow group <group-name> to read objectstorage-namespaces in tenancy enables users to obtain the auto-generated Object Storage namespace string of the tenancy, which is required to log in to Oracle Cloud Infrastructure Registry. This policy statement also provides access to function logs stored in a storage bucket in Oracle Cloud Infrastructure Object Storage (see Storing and Viewing Function Logs).

If you use the policy statement Allow group <group-name> to manage repos in tenancy to give users access to repositories in Oracle Cloud Infrastructure Registry, note that this policy statement gives the group permission to manage all repositories in the tenancy. If you consider this to be too permissive, then you can restrict the repositories to which the group has access by including a where clause in the manage repos statement. Note that if you do include a where clause, you must also include a second statement in the policy to enable the group to inspect all repositories in the tenancy (when using the Console). For example, the following policy statements restrict the group to accessing only repositories with names that start 'acme-web-app', but also enables the group to inspect all repositories in the tenancy:

Allow group acme-functions-developers to inspect repos in tenancy

Allow group acme-functions-developers to manage repos in tenancy where all {target.repo.name=/acme-web-app*/ }

When OCI Functions users create functions and applications, they have to specify a compartment for those function-related resources (including for metrics emitted by OCI Functions). Users can only specify a compartment that the groups to which they belong have been granted access. To enable users to specify a compartment, policy statements must grant the groups access to that compartment.

The policy statement Allow group <group-name> to manage functions-family in compartment <compartment-name> gives users access to function-related resources.

The policy statement Allow group <group-name> to read metrics in compartment <compartment-name> gives users access to metrics emitted by OCI Functions.

When OCI Functions users define an application, they can enable logging to store and view function logs in the Oracle Cloud Infrastructure Logging service. Users can only view logs that the groups to which they belong have been granted access. To enable users to store and view function logs in the Oracle Cloud Infrastructure Logging service, a policy statement must grant the groups access to logging resources.

The policy statement Allow group <group-name> to manage logging-family in compartment <compartment-name> gives users full access to logging resources in the compartment that will own logging resources

When OCI Functions users create a function or application, they have to specify a VCN and a subnet in which to create them. Users can only specify VCNs and subnets in compartments that the groups to which they belong have been granted access. To enable users to specify a VCN and subnet, a policy statement must grant the groups access to the compartment.

When OCI Functions users want to define ingress and egress rules that apply to all the functions in a particular application using an NSG, they can add the application to that NSG. To add an application to an NSG, a similar policy statement must grant the groups to which users belong access to the compartment to which the NSG belongs. Note that the NSG might belong to a different compartment to the function's subnet. For more information, see Adding Applications to Network Security Groups (NSGs).

When OCI Functions users want to investigate why a function doesn't run or perform as expected, they can use tracing to debug execution and performance issues. To use tracing, users have to enable tracing for the application containing the function, and then enable tracing for one or more functions. Users can then view function traces in the Application Performance Monitoring (APM) Trace Explorer. For more information, see Distributed Tracing for Functions.

Users can only enable tracing if the group to which they belong can access existing APM domains (or create new APM domains), and if OCI Functions can access APM domains. To enable users to turn on tracing and view traces, policy statements must grant the group and OCI Functions access to APM domains.

The policy statement Allow group <group-name> to use apm-domains in tenancy|compartment <compartment-name> gives users access to tracing resources in the compartment or in the entire tenancy. If you want to enable users to create new APM domains (and delete APM domains), specify manage apm-domains instead of use apm-domains.

The policy statement Allow service faas to use apm-domains in tenancy|compartment <compartment-name> gives OCI Functions access to APM domains in the compartment or in the entire tenancy.

Users can configure OCI Functions applications to only allow the creation, updating, deployment, and invocation of functions based on images in Oracle Cloud Infrastructure Registry that have been signed by particular master encryption keys.

To create a signature verification policy, and to create and deploy signed function images, users must have access to master encryption keys in vaults defined in Oracle Cloud Infrastructure Vault. Similarly, to enforce a signature verification policy defined for an application, the OCI Functionsservice must also have access to master encryption keys defined in Oracle Cloud Infrastructure Vault.

You can restrict the master encryption keys that can be used for function image signing, and signature verification. For example, by using policies like:

Allow service faas to {KEY_READ} in compartment <compartment-name> where target.key.id = '<ocid-of-key-in-verification-policy>' and request.operation = 'GetKeyVersion'

Allow service faas to {KEY_VERIFY} in compartment <compartment-name> where target.key.id = '<ocid-of-key-in-verification-policy>' and request.operation = 'Verify'

Allow group <groupname> to {KEY_READ} in compartment <compartment-name> where ALL {target.key.id = '<ocid-of-key-in-verification-policy>', ANY {request.operation = 'GetKey', request.operation = 'GetKeyVersion'}}

Allow group <groupname> to {KEY_VERIFY} in compartment <compartment-name> where target.key.id = '<ocid-of-key-in-verification-policy>' and request.operation = 'Verify'

For more information and examples, see Signing Function Images and Enforcing the Use of Signed Images from Registry.