Cloud Function Access Control

Cloud functions can be invoked through several entry points. CloudBase provides two permission control mechanisms: OPA Authorization Policy (recommended) and function-level security rules. This document explains which permission control applies to each access entry and how to configure function-level security rules. For the client scope of OPA, see OPA Authorization Policy.

Access Entry Points and Permission Mechanisms

Access Entry	Description	Permission Control
Client SDK calls (such as callFunction)	Web, mini program, and other clients call functions through the SDK	OPA Authorization Policy (recommended), security rules
HTTP API	Cross-language calls, third-party integration, standard REST API	OPA Authorization Policy
HTTP Gateway	Calls via a custom domain, browser environments	OPA Authorization Policy
Management API, timer triggers, database triggers	Internal platform calls	Not covered by the client-side controls above

OPA Authorization Policy (Recommended)

OPA authorization policies provide environment-level request authorization, covering all HTTP API and HTTP gateway requests in the environment. A request whose resource_type is functions is a cloud function call. Policies can combine conditions such as user identity, request path, HTTP method, and environment context to define access control rules that are more granular than function-level security rules.

Function-Level Security Rules

Function-level security rules are the function-level permission control feature of CloudBase SCF. They use simple expressions to precisely control which users can call specific cloud functions.

Scope of Application

Security rules only applicable to client call (like SDK method callFunction) and take effect, not suitable for the following scenarios:

• management console API calls
• Scheduled Trigger
• Database Trigger

Configuration Entry

On the CloudBase Platform/SCF, click the "permission control" button to enter the configuration page.

Basic syntax

SCF security rule configuration is at the environment level. ALL functions in the environment share a configuration file. The configuration uses JSON format:

{
  "function name or wildcard": {
    "invoke": "expression or boolean value"
  }
}

Configuration Structure Description

Configuration Item	Description	Example
Top-level key	Function name (specific function) or * (wildcard for ALL functions)	"*", "getUserInfo"
Operation key	Fixed as invoke, means call permission	"invoke"
Rule value	Boolean value or permission expression	See supported rule value descriptions below

Must-read

1. The top-level security rule configuration must include a wildcard configuration with the key *.
2. Each function configuration must include the invoke operation configuration.
3. The rule value supports true, false, "auth != null", or "auth.loginType != 'ANONYMOUS' && auth != null".
4. By default, the recommended configuration is "auth.loginType != 'ANONYMOUS' && auth != null" (only callable by login user, not by anonymous user).

Match Priority

1. Preferentially match the specific function name configuration
2. If the function name does not match, use the * wildcard configuration.

Supported rule values

SCF security rules support the following rule values:

Rule Value	Description	Use Cases
true	All are allowed (including unlogged-in users)	Public interface (search notice, config, etc.)
false	Forbid non-administrator access	Abandoned functions, internal call functions
"auth != null"	Only login users can call	Business function requiring user authentication
"auth.loginType != 'ANONYMOUS' && auth != null"	Callable by users with identities other than anonymous login	Business function not open to anonymous visitors

Supported expression examples:

• ✅ "auth != null" - Only login users
• ✅ "auth.loginType != 'ANONYMOUS' && auth != null" - Allow user invocation except anonymous login

Unsupported expression examples:

• ❌ "auth.uid != null" - Unsupported separate attribute access
• ❌ "auth != null && auth.loginType == 'WECHAT'" - Cannot be specified for specific login method
• ❌ "auth.openid != null || auth.uid != null" - Unsupported || operator

For finer permission control, implement business logic verification inside the cloud function, or use OPA authorization policies.

Common template

Exclude anonymous login users

{
  "*": {
    "invoke": "auth.loginType != 'ANONYMOUS' && auth != null"
  },
  "getPublicData": {
    "invoke": true
  }
}

-Default exclusion of anonymous login users, only allow logged in users to invoke

• getPublicData all are allowed to call

Login user callable

{
  "*": {
    "invoke": "auth != null"
  }
}

ALL functions require authentication by default and can be called after logging in, suitable for business systems that require authentication.

Partially public, partially restricted

{
  "*": {
    "invoke": "auth != null"
  },
  "getAnnouncement": {
    "invoke": true
  },
  "adminFunction": {
    "invoke": false
  }
}

-Default logon requirement

• getAnnouncement public access
• adminFunction completely forbids client invocation

ALL functions public

{
  "*": {
    "invoke": true
  }
}

⚠️ Warning: ALL functions allow anonymous call, exist security risks, applicable only to full public API.

ALL functions forbid non-admin calls

{
  "*": {
    "invoke": false
  }
}

ALL functions forbid non-admin calls.

FAQs

Can different permissions be set for different users?

The security rule supports the following rule values: true, false, "auth != null", and "auth.loginType != 'ANONYMOUS' && auth != null". It can use CAM for access control based on login status and whether the user is anonymous or not.

Unsupported permission control based on user role, user group, specific user ID, or other complex scenarios. For finer control based on user role, user group, request path, etc., we recommend OPA authorization policies; you can also verify inside SCF.

How to troubleshoot permission error?

When you encounter a PERMISSION_DENIED error, take the following steps to troubleshoot:

1. Check the security rule configuration: -Go to CloudBase Platform/SCF to check the control configuration for permission to view.
2. Confirm the user login status: -Use client SDK to check whether the user is logged in -For functions requiring "auth != null", complete login pre-invocation.
3. View error details: -For detailed error information, see the PERMISSION_DENIED error code.