Gateway Permission Control

"Gateway Permission" is the first line of defense for CloudBase resource access control. When you access CloudBase resources (cloud functions, CloudRun, cloud storage, AI capabilities, etc.) through HTTP API, Open API, or hosting domains, requests first reach the gateway layer, where the gateway decides based on configured policies:

• Allow: The request passes through the gateway and enters the resource layer for further authentication
• Deny: The request is blocked by the gateway and will not reach the resource layer

Authentication Order

Gateway authentication occurs before resource authentication. Taking cloud functions as an example:

Gateway Policy	Execution Status	Result
Not Allowed	Gateway rejects directly (403/No Permission)	Function will not be executed
Allowed	Request reaches cloud function	Continue resource layer/business layer authentication

Note

Gateway permissions only control "whether access is allowed", not "what can be done". Fine-grained data permissions should be implemented at the resource layer (such as database security rules) or business layer.

Configuration Entry

Go to CloudBase Console/Permission Control, select the target role → Enter role details page → Click "Add Custom Policy" → Select "Gateway" as the resource type.

Initial Permission Description

After environment initialization, the system automatically configures default gateway permissions. You can adjust them according to business needs:

Resource Type	Administrator	Organization Member	Registered User	Anonymous User
Cloud Functions/CloudRun/Cloud Storage	✅ All Available	✅ Most Available	⚠️ Partially Available	❌ Not Available by Default
International Storage Link	🔓 No Authentication (Controlled by Resource/Business Layer)	🔓 No Authentication	🔓 No Authentication	🔓 No Authentication

Security Note

Anonymous users cannot access resources through the gateway by default, preventing unauthenticated requests from directly penetrating backend services.

Policy Configuration

Gateway permissions support two types of policy configuration: preset policies and custom policies.

Preset Policies

The system provides commonly used preset policies that are ready to use out of the box, suitable for most scenarios.

Scenario 1: Development and Testing Phase - Full Administrator Access

• Use Case: Individual development, quick feature verification
• Recommended Policy: AdministratorAccess
• Advantages: No permission blocking, rapid iteration
• Precautions: ⚠️ Do not bind this policy to public-facing application identities in production environments

Scenario 2: Team Collaboration - Split by Resource Type

• Use Case: Multi-person collaborative development, division of labor by resource domain
• Recommended Policies:
  • StoragesAccess: Cloud storage access permission
  • FunctionsAccess: Cloud function access permission
  • CloudrunAccess: CloudRun access permission
• Advantages: Isolate permissions by resource, reduce risk of misoperation

Scenario 3: External Services - HTTP Access Control

• Use Case: Providing services externally via HTTP API
• Recommended Policies:
  • FunctionsHttpApiAllow / FunctionsHttpServiceAllow
  • CloudrunHttpApiAllow
  • StoragesHttpServiceAllow
• Best Practice: ⚡ First open the minimum permission set, then gradually expand according to needs

Custom Policies

When preset policies cannot meet requirements, you can customize policies to achieve fine-grained permission control.

Policy Syntax Description

A policy policy consists of a version version and statements statement. Each statement statement contains the following fields:

Field	Required	Description
effect	Required	Policy effect: allow (allow) or deny (deny)
action	Required	Operation type, format: feature_type:request_path Feature type refers to the feature list below Request path is the trigger path for HTTP access service Example: functions:* (all cloud function operations), functions:/hello (access /hello path)
resource	Required	Resource scope: Fixed fill * (representing all resources), fine-grained control is achieved through the action field

Feature List

Feature Type	Identifier
Cloud Storage	storages
Cloud Functions	functions
CloudRun	cloudrun
Large Model	ai
AI Agent	aibot
YuanQi	yuanqi
SQL Template	sql
ChatDB	chatdb
APIS	apis
Data Model	model
Knowledge Base	knowledge
AnyService	anyservice

Policy Structure Example (Allow Access to All Cloud Functions)

{
  "version": "1.0",
  "statement": [
    {
      "effect": "allow",
      "action": "functions:*",
      "resource": "*",
    }
  ]
}

Policy Priority Rules

When the same request matches multiple policies:

• ❌ deny takes priority over ✅ allow
• When no policy is matched, access is denied by default

Policy Priority

When both allow statements and deny statements exist, the deny priority principle applies.

Common Custom Policy Examples

Allow Specific Cloud Function

Allow HTTP access to the cloud function with path /hello:

{
  "version": "1.0",
  "statement": [
    {
      "effect": "allow",
      "action": "functions:/hello",
      "resource": "*"
    }
  ]
}

Deny Dangerous Operations

Deny access to specific sensitive cloud functions:

{
  "version": "1.0",
  "statement": [
    {
      "effect": "deny",
      "action": "functions:/dangerousFunction",
      "resource": "*"
    }
  ]
}

Cloud Storage Access

Allow access to all cloud storage resources:

{
  "version": "1.0",
  "statement": [
    {
      "effect": "allow",
      "action": "storages:*",
      "resource": "*"
    }
  ]
}

Mixed Policy

Allow access to all cloud functions, but deny access to specific sensitive functions (deny has higher priority):

{
  "version": "1.0",
  "statement": [
    {
      "effect": "allow",
      "action": "functions:*",
      "resource": "*"
    },
    {
      "effect": "deny",
      "action": "functions:/admin",
      "resource": "*"
    }
  ]
}

Best Practices

Least Privilege Principle

Follow the "Least Privilege" principle and grant permissions according to actual needs:

Identity Type	Recommended Policy	Description
Developer/Administrator	AdministratorAccess	High permissions can be used during development phase to improve efficiency
Production Environment Application	Custom Policy	Only grant necessary action + resource
Automation Service	Minimum Permission Set	CI/CD, scheduled tasks, etc. only open required interfaces

Layered Defense Strategy

Security protection should be implemented at multiple levels, rather than relying on a single mechanism:

┌─────────────────────────────────────────┐
│  Gateway Layer (Gateway Permission)      │  ← Controls "whether access is allowed"
│  • Determines whether requests can        │
│    enter the resource layer               │
│  • Controls access based on role/IP/time  │
│    and other conditions                   │
└─────────────────────────────────────────┘
              ↓ Allow
┌─────────────────────────────────────────┐
│  Resource Layer (Security Rules)         │  ← Controls "what can be done"
│  • Database security rules                │
│  • Cloud storage access control           │
│  • Cloud function authentication config   │
└─────────────────────────────────────────┘
              ↓ Pass
┌─────────────────────────────────────────┐
│  Business Layer (Application Auth)       │  ← Controls "fine-grained permissions"
│  • User role verification                 │
│  • Data permission filtering              │
│  • Business rule restrictions (quotas,    │
│    risk control, etc.)                    │
└─────────────────────────────────────────┘

Policy Configuration Recommendations

1. Prioritize Using Preset Policies

• ✅ Preset policies have been thoroughly tested, more standardized and less error-prone
• ⚠️ Custom policies need to be thoroughly tested before production use

2. Use deny for Global Fallback

When you need to "globally prohibit certain dangerous operations", use deny policy (because deny has higher priority than allow):

{
  "effect": "deny",
  "action": "functions:*",
  "resource": "*"
}

3. Regularly Review Permission Configuration

• Regularly check whether the permission configuration of each role is reasonable
• Promptly revoke permissions that are no longer needed
• Monitor abnormal access logs and adjust policies

Troubleshooting Path

When encountering permission issues, troubleshoot in the following order:

Symptom	Investigation Focus	Handling Direction
Request returns 403, resource log has no record	Gateway policy	Check gateway permission configuration, confirm whether policy allows
Request enters resource but execution fails	Resource layer security rules	Check database security rules, cloud storage permissions, etc.
Resource layer passes, business logic error	Business layer authentication	Check permission verification logic in application code

Debugging Tips

You can temporarily change the role policy to AdministratorAccess. If the problem disappears, it indicates a gateway permission configuration issue; if the problem persists, you need to check the resource layer or business layer.