Orchestration Cluster authorization

Camunda 8's Orchestration Cluster provides a fine-grained authorization system for controlling access to web components and APIs. This system applies to:

• Zeebe
• Operate
• Tasklist
• Orchestration Cluster APIs (e.g., V2 API)

note

Authorization applies only to these orchestration components. It does not apply to other Camunda services, such as Web Modeler or Optimize.

Core concepts

Authorization model

• Based on the principle of least privilege.
• Can be enabled or disabled in both SaaS and Self-Managed environments.
• When disabled: all users and clients have full access.
• When enabled: no access is granted by default; explicit authorization is required.
• No concept of deny rules—absence of permission means no access.
• Enforced across both web components and API requests.

Key components

1. Authorizations

   • Assign permissions to Identities for specific resources.
   • Examples:
     • User jonny is authorized to create new users.
     • Group marketing is authorized to delete the group sales.

2. Owners

   • Types include users, groups, roles, clients and mapping rules.
   • Authorizations can be assigned to any type of owner.

3. Permissions

   • Define allowed interactions with resources.
   • Are specific to each resource type.

4. Resources

   • Entities users interact with.
   • Each resource has its own set of permissions.

Configuration

SaaS configuration

In Camunda 8 SaaS, authorizations can be enabled or disabled per cluster. This setting can be changed by:

• Organization admins
• Organization owners

Self-Managed configuration

In Self-Managed deployments, enable the authorization system using:

application.yaml

camunda.security.authorizations.enabled: true

Environment variables

CAMUNDA_SECURITY_AUTHORIZATIONS_ENABLED=true

Helm values

orchestration.security.authorizations.enabled=true

Resources and permissions

Available resources

The following table lists all resources that support authorization in Camunda 8 Orchestration Cluster, along with the available permissions per resource. This applies to Camunda 8 Orchestration Cluster (Zeebe, Operate, Tasklist, Orchestration Cluster APIs).

Resource type	Resource key example	Resource key type	Supported permissions
Authorization	*	All authorizations	CREATE, READ, UPDATE, DELETE
Batch	*	All batches	CREATE, CREATE_BATCH_OPERATION_CANCEL_PROCESS_INSTANCE, CREATE_BATCH_OPERATION_DELETE_PROCESS_INSTANCE, CREATE_BATCH_OPERATION_MIGRATE_PROCESS_INSTANCE, CREATE_BATCH_OPERATION_MODIFY_PROCESS_INSTANCE, CREATE_BATCH_OPERATION_RESOLVE_INCIDENT, CREATE_BATCH_OPERATION_DELETE_DECISION_INSTANCE, CREATE_BATCH_OPERATION_DELETE_DECISION_DEFINITION, CREATE_BATCH_OPERATION_DELETE_PROCESS_DEFINITION, READ, UPDATE
Component	*, operate, tasklist, identity	All components, component name	ACCESS
Decision Definition	*, order_decision	All decisions / Decision ID	CREATE_DECISION_INSTANCE, READ_DECISION_DEFINITION, READ_DECISION_INSTANCE, DELETE_DECISION_INSTANCE
Decision Requirements Definition	*, order_decision	All DRDs / DRD ID	READ
Document	*	All Documents	CREATE, READ, DELETE
Group	*, accounting	All groups / Group ID	CREATE, READ, UPDATE, DELETE
Mapping Rule	*, my_mapping	All mappings / Mapping ID	CREATE, READ, UPDATE, DELETE
Message	*	All messages	CREATE, READ
Process Definition	*, order_process	All processes / BPMN Process ID	CREATE_PROCESS_INSTANCE, READ_PROCESS_DEFINITION, READ_PROCESS_INSTANCE, READ_USER_TASK, UPDATE_PROCESS_INSTANCE, UPDATE_USER_TASK, MODIFY_PROCESS_INSTANCE, CANCEL_PROCESS_INSTANCE, DELETE_PROCESS_INSTANCE
Resource	*, my_form, order_process	All resources / Form ID / Process ID	CREATE, READ, DELETE_DRD, DELETE_FORM, DELETE_PROCESS, DELETE_RESOURCE
Role	*, myrole	All roles / Role ID	CREATE, READ, UPDATE, DELETE
System	*	All system operations	READ, READ_USAGE_METRIC, UPDATE
Tenant	*, tenantA	All tenants / Tenant ID	CREATE, READ, UPDATE, DELETE
User	*, felix.mueller	All users / Username	CREATE, READ, UPDATE, DELETE

Security considerations

Certain permissions grant powerful capabilities and should be assigned with caution. It is critical to ensure that only trusted users and clients are granted these permissions to maintain the security and integrity of your system.

Resource CREATE permission (deployment)

Granting CREATE permission on the Resource is equivalent to allowing remote code execution. When a user deploys a BPMN model, it can contain executable code in script tasks, service tasks, or listeners that will be run by the process engine.

Only grant this permission to users and clients who are fully trusted to deploy and execute code in your environment.

User CREATE/UPDATE permissions

The CREATE and UPDATE permissions for the User resource are highly sensitive. When a user's password is set or changed via Identity, there are no security controls enforced, such as password complexity policies.

This permission should only be assigned to trusted administrators.

System access permissions

Permissions that control system access are particularly security-sensitive. This includes CRUD operations to the following resources:

• System
• User
• Group
• Role
• Mapping rule
• Tenant

These permissions should be strictly limited to trusted system administrators who are responsible for managing user access control.

Default roles

Camunda provides predefined roles to simplify access management:

Role ID	Purpose	Typical authorizations
admin	Full control over all Orchestration Cluster resources and components.	All permissions for all resources: READ, CREATE, UPDATE, DELETE, including ACCESS to all web components.
readonly-admin	Audit-focused users who need read-only access across the Orchestration Cluster.	READ for all resources, including READ_PROCESS_DEFINITION, READ_PROCESS_INSTANCE, READ_USER_TASK, etc.
connectors	Technical role for executing connector calls.	READ_PROCESS_DEFINITION on Process Definition (*), UPDATE_PROCESS_INSTANCE on Process Definition (*), CREATE on Message (*), CREATE, READ, and DELETE on Document
rpa	Role for RPA workers.	READ on Resource (*), UPDATE_PROCESS_INSTANCE on Process Definition (*)

Role assignment in SaaS

• admin: Automatically assigned to Organization Owner and Admin
• connectors: Automatically assigned to Connectors Runtime in Cluster deployment
• readonly-admin: Automatically assigned to Camunda Support Agents for support cases

Common use cases

Web component access

Users need specific permissions to access Orchestration Cluster web components:

• UI access: Resource type Component and Resource Key is one of the components Operate, Tasklist, Identity
  • Example: operate for Operate access
  • Example: tasklist for Tasklist access
  • Example: identity for Identity access
  • Example: * for access to all components
• Without these permissions, users cannot log in to the components

Resource access

Within components, users need additional permissions for specific resources, e.g.:

• Process related: Resource type processDefinition
  • READ_PROCESS_DEFINITION to view process models
  • CREATE_PROCESS_INSTANCE to start new processes
  • UPDATE_PROCESS_INSTANCE to update running instances
  • MODIFY_PROCESS_INSTANCE to modify running instances
  • CANCEL_PROCESS_INSTANCE to cancel running instances
  • DELETE_PROCESS_INSTANCE to delete completed instances
• Decision related: Resource type decisionDefinition
  • READ_DECISION_DEFINITION to view DMN models
  • CREATE_DECISION_INSTANCE to execute decisions

API access

When implementing your own integrations (e.g., using a Camunda client), you should consider the following:

• Job workers: Resource type processDefinition
  • UPDATE_PROCESS_INSTANCE to complete jobs for the specific process definitions