Security Authorization Changes

Most authorization permissions remain unchanged. Before you start GridGain 8, check your configuration for the nine Apache Ignite 2.x permission names that GridGain 8 no longer recognizes, and replace or remove them using the table below.

Three differences require attention. They stem from fine-grained authorization permissions that Apache Ignite 2.18 defines but GridGain 8 does not:

All other permission names keep the same behavior, including cache, task, service, event, and the remaining administrative permissions. For the complete list, see Authorization and Permissions.

Apache Ignite 2 split cluster administration into fine-grained permissions so you could, for example, allow a role to change cluster state but not stop nodes. GridGain 8 does not have that split. Cluster-state changes, baseline changes, node start/stop, snapshot operations, and rolling-upgrade control all require ADMIN_OPS.

A role that needs any one of these actions effectively gets all of them. If your Ignite policy assigned these operations to different roles, GridGain 8 cannot preserve that separation, because they all require ADMIN_OPS. Review whether the broader ADMIN_OPS grant is acceptable under your least-privilege requirements before you migrate those roles.

Cancellation operations are a related case. Apache Ignite grouped them under the ADMIN_KILL permission. GridGain 8 replaces only SQL query cancellation, with KILL_QUERY. Other cancellation operations (compute tasks, services, transactions, continuous and scan queries) are authorized as part of the underlying operation rather than by a dedicated kill permission. Review each cancellation workflow individually instead of assuming a single replacement permission.

In Apache Ignite 2, creating, altering, and dropping users is controlled by the ADMIN_USER_ACCESS permission. GridGain 8 uses a fixed rule instead. With built-in authentication:

This rule is not configurable and is not tied to any grant.

What to do: remove ADMIN_USER_ACCESS from your policy. If your Ignite setup let a non-default administrative role manage users, that arrangement does not carry over. Perform user administration using the default ignite user. To delegate user administration to other roles, use GridGain enterprise security with an external identity provider rather than built-in authentication.

GridGain 8 uses the H2 SQL engine and does not support user-defined SQL views. Remove SQL_VIEW_CREATE and SQL_VIEW_DROP from your policy.

Most deployments configure security through files and never touch code. If you are the exception and built a custom security provider in Java that references the removed permission names directly, that code will not compile against GridGain 8, because GridGain’s SecurityPermission enum does not define the corresponding constants. Replace those references according to Permissions that changed: use ADMIN_OPS, use KILL_QUERY, or remove the permission entirely. Only the permissions listed in Authorization and Permissions are valid.