> For the complete documentation index, see [llms.txt](https://mariadb.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mariadb.com/docs/gridgain/gridgain-8/gridgain8-management/migration-guides/apache-ignite-2x-8.10/security-authorization.md).

# Security Authorization Changes

How to migrate authorization from a secured Apache Ignite 2.18 cluster to GridGain 8.10: retired permissions, coarser admin grants, and user management.

This page explains how to migrate authorization when moving a secured Apache Ignite 2.18 cluster to GridGain 8.10. It covers the authorization differences that affect users, roles, and administrative operations. It applies to Ignite 2 and GridGain 8.10. Earlier 2.x releases may not have some of these permissions.

To move a custom `GridSecurityProcessor` or Ignite 2 built-in authentication to GridGain enterprise security, see the *Custom security plugins* entry in [Features to Replace](/docs/gridgain/gridgain-8/gridgain8-management/migration-guides/apache-ignite-2x-8.10/features-to-replace.md). For the full list of permission names and how to configure them, see [Authorization and Permissions](/docs/gridgain/gridgain-8/security/authentication-and-authorization/authorization-permissions.md).

## Overview

Most authorization permissions remain unchanged. Before you start GridGain 8.10, check your configuration for the nine Ignite 2 permission names that GridGain 8 no longer defines, and replace or remove them using the [table below](#permissions-that-changed).

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

* Nine fine-grained permissions are not part of GridGain 8's permission set. Replace or remove them. See [Permissions That Changed](#permissions-that-changed).
* Some admin operations are now authorized by the single `ADMIN_OPS` permission instead of separate ones. See [Coarser Admin Permissions](#coarser-admin-permissions).
* User management no longer uses a grantable permission and follows a fixed rule. See [User Management](#user-management).

{% hint style="warning" %}
GridGain 8.10 reads seven of the nine retired names from JSON-based security configuration and drops each one with a `WARN` log line: `ADMIN_KILL`, `ADMIN_CLUSTER_STATE`, `ADMIN_USER_ACCESS`, `ADMIN_CLUSTER_NODE_START`, `ADMIN_CLUSTER_NODE_STOP`, `SQL_VIEW_CREATE`, and `SQL_VIEW_DROP`. The log line reads `Ignoring an Apache Ignite 2.x security permission that does not exist in GridGain (from a migrated permission set): ADMIN_KILL`. They are *not* mapped to `ADMIN_OPS`, so a role that relied on them loses the grant.

`ADMIN_SNAPSHOT`, `ADMIN_ROLLING_UPGRADE`, and any other unknown name are still rejected: the security configuration fails to parse (`Unexpected token (expected one of [CACHE_READ, CACHE_PUT, ...])`) and the node does not start. Code that assigns permissions through the `SecurityPermission` enum, in Java or Spring, does not compile if it uses a retired constant, because those constants do not exist.

*Replace or remove all nine permissions before you start the cluster, and search the startup log for the warnings.*
{% endhint %}

## Permissions That Changed

| Permission in your Ignite 2 policy                     | What it controlled                                                                  | What to do on GridGain 8                                                                                                                                          |
| ------------------------------------------------------ | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ADMIN_CLUSTER_STATE`                                  | Activate / deactivate / change cluster state                                        | Grant `ADMIN_OPS`.                                                                                                                                                |
| `ADMIN_CLUSTER_NODE_START` / `ADMIN_CLUSTER_NODE_STOP` | Start / stop / restart nodes                                                        | Grant `ADMIN_OPS`.                                                                                                                                                |
| `ADMIN_SNAPSHOT`                                       | Create / restore / cancel snapshots                                                 | Grant `ADMIN_OPS`. The node does not start if this permission stays in the configuration.                                                                         |
| `ADMIN_ROLLING_UPGRADE`                                | Enable rolling upgrade and change its mode                                          | Grant `ADMIN_OPS`. The node does not start if this permission stays in the configuration.                                                                         |
| `ADMIN_KILL`                                           | Cancel running compute tasks, services, transactions, queries (the `--kill` family) | Grant `KILL_QUERY` for SQL query cancellation. Other cancellation types have no single replacement (see [Coarser Admin Permissions](#coarser-admin-permissions)). |
| `ADMIN_USER_ACCESS`                                    | Create / alter / drop users                                                         | Remove it. User management is not a permission (see [User Management](#user-management)).                                                                         |
| `SQL_VIEW_CREATE` / `SQL_VIEW_DROP`                    | Create / drop user-defined SQL views                                                | Remove them. GridGain 8 has no user-defined SQL views.                                                                                                            |

All other permission names keep the same behavior, including cache, task, service, event, and the remaining administrative permissions. GridGain 8.10 also adds permissions that Ignite 2 does not have: `COPY_FROM_FILE` and `COPY_TO_FILE` (required for server-side SQL `COPY`), and `CUSTOM_METRICS_MANAGE` (custom metrics API). If your roles run these operations, grant the new permissions. `SERVICE_INVOKE` is now also checked for thin-client calls to remote Java services. For the complete list, see [Authorization and Permissions](/docs/gridgain/gridgain-8/security/authentication-and-authorization/authorization-permissions.md).

## Coarser Admin Permissions

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 2 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. Ignite 2 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.

## User Management

In 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:

* Only the default user (`ignite`) may create, alter, or drop other users.
* Any other user may change only their own password.
* The default user cannot be deleted.

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 2 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.

## User-Defined SQL Views

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.

## If You Maintain a Custom Security Implementation

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 8's `SecurityPermission` enum does not define the corresponding constants. Replace those references according to [Permissions That Changed](#permissions-that-changed): use `ADMIN_OPS`, use `KILL_QUERY`, or remove the permission entirely. Only the permissions listed in [Authorization and Permissions](/docs/gridgain/gridgain-8/security/authentication-and-authorization/authorization-permissions.md) are valid.

## Migration Checklist

1. Locate permission grants in your security configuration (role definitions, permission sets) that name any of the nine changed permissions.
2. Replace or remove them per [Permissions That Changed](#permissions-that-changed): cluster, node, snapshot, and rolling-upgrade admin → `ADMIN_OPS`; SQL kill → `KILL_QUERY`; user management and SQL views → remove.
3. Move user administration to the default `ignite` user and drop `ADMIN_USER_ACCESS`.
4. Review any role that now requires the broader `ADMIN_OPS`, and confirm that is acceptable under least privilege.
5. Start a secured node and check the log. A `WARN` line naming a retired permission means the grant was dropped: add its replacement. A parse failure on `ADMIN_SNAPSHOT`, `ADMIN_ROLLING_UPGRADE`, or another unknown name means the node did not start: remap the permission before retrying.
6. Test each migrated role end to end: cluster activate/deactivate, baseline change, node stop, SQL `KILL QUERY`, and user create/drop.