Skip to main content
Version: 5.3
Enterprise Edition
This feature requires Hazelcast Enterprise, a licensed edition of the Hazelcast Platform.

Client Security

To protect your members from a malicious client, you can allow them to identify clients and restrict their permissions to access either data in data structures or features such as user code deployment.

To allow members to identify clients, set up client authentication.

To allow members to restrict client permissions, set up client authorization.

Authenticating Clients​

To implement the client authentication, reference a Security Realm with the authentication section defined in the client-authentication setting of a cluster member's configuration.

The authentication configuration defines a method used to verify the client's identity and assign its roles.

xml
<hazelcast>
    ...
    <security enabled="true">
      <realms>
          <realm name="clientRealm">
              <authentication>
                <ldap>
                    <url>ldap://corp-ldap.example.com/</url>
                    <role-mapping-attribute>cn</role-mapping-attribute>
                </ldap>
              </authentication>
          </realm>
      </realms>
      <client-authentication realm="clientRealm"/>
    </security>
    ...
</hazelcast>

The identity of the connecting client is defined on the client side. Usually, there are no security realms on the clients, but just identity defined directly in the security configuration.

xml
<hazelcast-client>
    ...
    <security>
      <username-password username="uid=member1,dc=example,dc=com" password="s3crEt"/>
    </security>
    ...
</hazelcast-client>

On the clients, you can use the same identity types as in security realms:

  • username-password
  • token
  • kerberos (may require an additional security realm definition)
  • credentials-factory

Authorizing Clients​

Hazelcast client authorization is configured by a client permission policy. Hazelcast has a default permission policy implementation that uses permission configurations defined in the Hazelcast security configuration. Default policy permission checks are done against instance types (map, queue, etc.), instance names, instance actions (put, read, remove, add, etc.), the client endpoint address (ClusterEndpointPrincipal), and client roles (ClusterRolePrincipal).

The default permission policy allows to use comma separated names in the principal attribute configuration.

note

Unless part of the role name, do not include spaces when adding names to the principal attribute.

Hazelcast does not automatically remove spaces in role names. If you include spaces that are not part of the name, permission is not granted to the intended role.

For example, if you configure permissions for the admin and devel roles using principal=" admin ,devel", the admin role is not granted the permission.

You can define the instance and principal names as wildcards using the "*" character. See the Using Wildcards section for details.

The endpoint names can use range characters "-" and "*" as described in the Interfaces section.

xml
<hazelcast>
    ...
    <security enabled="true">
        <client-permissions>
            <!-- Principals 'admin' and 'root' from endpoint '127.0.0.1' have all permissions. -->
            <all-permissions principal="admin,root">
                <endpoints>
                    <endpoint>127.0.0.1</endpoint>
                </endpoints>
            </all-permissions>

            <!-- Principals named 'dev' from all endpoints have 'create', 'destroy',
            'put', 'read' permissions for map named 'myMap'. -->
            <map-permission name="myMap" principal="dev">
                <actions>
                    <action>create</action>
                    <action>destroy</action>
                    <action>put</action>
                    <action>read</action>
                </actions>
            </map-permission>

            <!-- All principals from endpoints '127.0.0.1' or matching to '10.10.*.*'
            have 'put', 'read', 'remove' permissions for map
            whose name matches to 'com.foo.entity.*'. -->
            <map-permission name="com.foo.entity.*">
                <endpoints>
                    <endpoint>10.10.*.*</endpoint>
                    <endpoint>127.0.0.1</endpoint>
                </endpoints>
                <actions>
                    <action>put</action>
                    <action>read</action>
                    <action>remove</action>
                </actions>
            </map-permission>

            <!-- Principals named 'dev' from endpoints matching either
            '192.168.1.1-100' or '192.168.2.*'
            have 'create', 'add', 'remove' permissions for all queues. -->
            <queue-permission name="*" principal="dev">
                <endpoints>
                    <endpoint>192.168.1.1-100</endpoint>
                    <endpoint>192.168.2.*</endpoint>
                </endpoints>
                <actions>
                    <action>create</action>
                    <action>add</action>
                    <action>remove</action>
                </actions>
            </queue-permission>

           <!-- All principals from all endpoints have transaction permission.-->
           <transaction-permission />
       </client-permissions>
    </security>
    ...
</hazelcast>

You can also define your own policy by implementing com.hazelcast.security.IPermissionPolicy.

java
package com.hazelcast.security;
/**
 * IPermissionPolicy is used to determine any Subject's
 * permissions to perform a security sensitive Hazelcast operation.
 *
 */
public interface IPermissionPolicy {
  void configure( SecurityConfig securityConfig, Properties properties );

  PermissionCollection getPermissions( Subject subject,
                                       Class<? extends Permission> type );

  void destroy();
}

Permission policy implementations can access client-permissions that are in the configuration by using SecurityConfig.getClientPermissionConfigs() when Hazelcast calls the configure(SecurityConfig securityConfig, Properties properties) method.

The IPermissionPolicy.getPermissions(Subject subject, Class<? extends Permission> type) method is used to determine a client request that has been granted permission to perform a security-sensitive operation.

Permission policy should return a PermissionCollection containing permissions of the given type for the given Subject. The Hazelcast access controller calls PermissionCollection.implies(Permission) on returning PermissionCollection and it decides whether the current Subject has permission to access the requested resources.

Permissions​

The following is the list of client permissions that can be configured on the member:

All Permission​

This permission grants clients access to all data and features.

xml
<all-permissions principal="principal">
    <endpoints>
        ...
    </endpoints>
</all-permissions>

Management Permission​

This permission defines which client principals/endpoints are allowed to perform management tasks. Here, the client we mention is the one that is used by Hazelcast Management Center when it connects to the clusters. To learn more about this client, see Cluster Connections.

xml
<management-permission principal="mcadmin">
    <endpoints>
        ...
    </endpoints>
</management-permission>

Map Permission​

Actions: all, create, destroy, index, intercept, listen, lock, put, read, remove

xml
<map-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</map-permission>

Queue Permission​

Actions: add, all, create, destroy, listen, read, remove

xml
<queue-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</queue-permission>

Multimap Permission​

Actions: all, create, destroy, listen, lock, put, read, remove

xml
<multimap-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
     </actions>
</multimap-permission>

Replicated Map Permission​

Actions: all, create, destroy, index, intercept, listen, lock, put, read, remove

xml
<replicatedmap-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
     </actions>
</replicatedmap-permission>

Topic Permission​

Actions: create, destroy, listen, publish

xml
<topic-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</topic-permission>

Reliable Topic Permission​

Actions: create, destroy, listen, publish

xml
<reliable-topic-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</reliable-topic-permission>

List Permission​

Actions: add, all, create, destroy, listen, read, remove

xml
<list-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</list-permission>

Set Permission​

Actions: add, all, create, destroy, listen, read, remove

xml
<set-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</set-permission>

Ringbuffer Permission​

Actions: add, put, read, create, destroy

xml
<ring-buffer-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</ring-buffer-permission>

Lock Permission​

Actions: all, create, destroy, lock, read

xml
<lock-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</lock-permission>

AtomicLong Permission​

Actions: all, create, destroy, modify, read

xml
<atomic-long-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</atomic-long-permission>

AtomicReference Permission​

Actions: all, create, destroy, modify, read

xml
<atomic-reference-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</atomic-reference-permission>

CountDownLatch Permission​

Actions: all, create, destroy, modify, read

xml
<countdown-latch-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</countdown-latch-permission>

FlakeIdGenerator Permission​

Actions: all, create, destroy, modify, read

xml
<flake-id-generator-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</flake-id-generator-permission>

Semaphore Permission​

Actions: all, acquire, create, destroy, read, release

xml
<semaphore-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</semaphore-permission>

Executor Service Permission​

Actions: all, create, destroy

xml
<executor-service-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</executor-service-permission>

Durable Executor Service Permission​

Actions: all, create, destroy

xml
<durable-executor-service-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</durable-executor-service-permission>

Scheduled Executor Service Permission​

Actions: all, create, destroy, read, modify

xml
<scheduled-executor-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</scheduled-executor-permission>

Cardinality Estimator Permission​

Actions: all, create, destroy, read, modify

xml
<cardinality-estimator-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</cardinality-estimator-permission>

PN Counter Permission​

Actions: all, create, destroy, read, modify

xml
<pn-counter-permission name="name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</pn-counter-permission>

Transaction Permission​

xml
<transaction-permission principal="principal">
    <endpoints>
        ...
    </endpoints>
</transaction-permission>

Cache Permission​

Actions: all, create, destroy, listen, put, read, remove

xml
<cache-permission name="/hz/cache-name" principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</cache-permission>
note

The name provided in cache-permission must be the Hazelcast distributed object name corresponding to the Cache as described in the JCache - Hazelcast Instance Integration section.

User Code Deployment Permission​

Actions: all, deploy

xml
<user-code-deployment-permission principal="principal">
    <endpoints>
        ...
    </endpoints>
    <actions>
        ...
    </actions>
</user-code-deployment-permission>

Configuration Permission​

This permission defines which client principals/endpoints are allowed to add data structure configurations at runtime.

xml
<config-permission principal="principal">
    <endpoints>
        <endpoint>...</endpoint>
    </endpoints>
</config-permission>

Job Permission​

Actions:

  • submit: Submit a new job, without uploading resources.

  • cancel: Cancel a running job.

  • read: Get or list information about a job (by ID or name) such as job configuration, job status, and submission time.

    warning

    When you query a streaming source with SQL, Hazelcast runs that query as a job. As a result, clients with the read permission for jobs can see the SQL query and any parameters.

  • restart: Suspend and resume a running job.

  • export-snapshot: Export or read snapshots.

  • add-resources: Upload resources and classes as well as jobs to members.

    warning

    Hazelcast cannot check permissions in code that's uploaded with a job, If you enable this permission, clients can upload custom code that ignores any configured permissions.

  • all: Enable all actions.

All actions for job permissions also enable the read action. For example if you enable the create action, the read action is automatically enabled as well.

xml
<job-permission principal="principal">
    <actions>
        <action>...</action>
    </actions>
</job-permission>

Connector Permission​

You can give permissions to the following connectors:

  • File
  • Socket

Actions:

  • read: Read data from sources.
  • write: Write data to sinks.
  • all: Enable all actions.
File Connector
xml
<!-- It is currently only possible to give access to a whole directory, not to a single file. -->
<connector-permission name="file:directory_name">
    <actions>
        <action>...</action>
    </actions>
</connector-permission>
Socket Connector
xml
<connector-permission name="socket:host:port">
    <actions>
        <action>...</action>
    </actions>
</connector-permission>
warning

To protect external systems from being reached by external connectors (JDBC, Mongo, S3, …​), use other means than Hazelcast client permissions. Traditionally, this is done by enabling authentication on the external system and/or setting up firewall rules.

SQL Permission​

You can give clients permission to use the following SQL statements:

Actions:

  • create: Use the CREATE MAPPING statement to create new mappings or replace existing ones.
  • destroy: Use the DROP MAPPING statement to delete mappings.
  • create-index: Use the CREATE INDEX statement to create a new index for a map.
  • create-view: Use the CREATE VIEW statement to create new views or replace existing ones.
  • drop-view: Use the DROP VIEW statement to delete an existing view.
  • create-dataconnection: Use the CREATE DATA CONNECTION statement to create new data connections or replace existing ones.
  • drop-dataconnection: Use the DROP DATA CONNECTION statement to delete data connections.
  • view-dataconnection: Use the SHOW RESOURCES statement to view the resources and data types accessible via data connections.
  • all: Enable all actions.

To apply permissions to certain mappings or data connections, provide their names in the name attribute. Or, you can apply permissions to all mappings and data connections using the * wildcard.

Apply permissions to a mapping
xml
<sql-permission name="mapping_name">
  <actions>
    <action>create</action>
    <action>destroy</action>
  </actions>
</sql-permission>
Apply permissions to all mappings
xml
<sql-permission name="*">
  <actions>
    <action>create</action>
    <action>destroy</action>
  </actions>
</sql-permission>
Apply permissions to a data connection
xml
<sql-permission name="data_connection_name">
  <actions>
    <action>drop-dataconnection</action>
    <action>view-dataconnection</action>
  </actions>
</sql-permission>

Handling Permissions When a New Member Joins​

By default, the set of permissions defined in the leader member of a cluster is distributed to the newly joining members, overriding their own permission configurations, if any. However, you can configure a new member to be joined, so that it keeps its own set of permissions and even send these to the existing members in the cluster. This can be done dynamically, without needing to restart the cluster, using either one of the following configuration options:

  • the on-join-operation configuration attribute
  • the setOnJoinPermissionOperation() method

Using the above, you can choose whether a new member joining to a cluster will apply the client permissions stored in its own configuration, or use the ones defined in the cluster. The behaviors that you can specify with the configuration are RECEIVE, SEND and NONE, which are described after the examples below.

The following are the examples for both approaches on how to use them:

Declarative Configuration:

xml
<hazelcast>
    ...
    <security enabled="true">
        <client-permissions on-join-operation="SEND">
            <!-- ... -->
        </client-permissions>
    </security>
    ...
</hazelcast>

Programmatic Configuration:

java
Config config = new Config();
config.getSecurityConfig()
    .setEnabled(true)
    .setOnJoinPermissionOperation(OnJoinPermissionOperationName.SEND);

The behaviors are explained below:

  • RECEIVE: Applies the permissions from the leader member in the cluster before join. This is the default value.

  • SEND: Doesn't apply the permissions from the leader member before join. If the security is enabled, then it refreshes or replaces the cluster wide permissions with the ones in the new member after the join is complete. This option is suitable for the scenarios where you need to replace the cluster wide permissions without restarting the cluster.

  • NONE: Neither applies pre-join permissions, nor sends the local permissions to the other members. It means that the new member does not send its own permission definitions to the cluster, but keeps them when it joins. However, after the join, when you update the permissions in the other cluster members, those updates are also sent to the newly joining member. Therefore, this option is suitable for the scenarios where you need to elevate privileges temporarily on a single member (preferably a lite member) for a limited time period. The clients which want to use these temporary permissions have to access the cluster through this single new member, meaning that you need to disable smart routing for such clients.

    Note that, the create and destroy permissions will not work when using the NONE option, since the distributed objects need to be created/destroyed on all the members.

    The following is an example for a scenario where NONE is used:

    java
    // temporary member, in the below case a lite member
    Config config = new Config().setLiteMember(true);
    PermissionConfig allPermission = new PermissionConfig(PermissionType.ALL, "*", null);
    config.getSecurityConfig()
      .setEnabled(true)
      .setOnJoinPermissionOperation(OnJoinPermissionOperationName.NONE)
      .addClientPermissionConfig(allPermission);
    HazelcastInstance hzLite = Hazelcast.newHazelcastInstance(config);

    // temporary client connecting only to the lite member
    String memberAddr = ...;
    ClientConfig clientConfig = new ClientConfig();
    clientConfig.getNetworkConfig().setSmartRouting(false)
      .addAddress(memberAddr);
    HazelcastInstance client = HazelcastClient.newHazelcastClient(clientConfig);

    // do operations with escalated privileges:
    client.getMap("protectedConfig").put("master.resolution", "1920");

    // shutdown the client and lite member
    client.shutdown();
    hzLite.shutdown();
Edit this page