Secured Connectivity

If you have security enabled on your cluster, then the Web Console and the Web Agent will need authorization to access the cluster.

Connecting to a Secured Cluster

Connect the Web Console to a secured cluster via the following steps:

Set the security credentials and permissions for the Web Agent and for the Web Console users. The Web Agent doesn’t require any special permissions.

Configure this in the Ignite XML configuration file. For example, let’s say the cluster is configured with the following set of permissions:

<!-- Credentials for cluster nodes. -->
<bean id="node.credentials" class="org.apache.ignite.plugin.security.SecurityCredentials">
    <constructor-arg value="node"/>
    <constructor-arg value="password"/>
</bean>

<!-- Credentials for the Web Console user. -->
<bean id="web-console-user.credentials" class="org.apache.ignite.plugin.security.SecurityCredentials">
    <constructor-arg value="user"/>
    <constructor-arg value="12345"/>
</bean>

<!-- Credentials for the Web Agent. -->
<bean id="web-agent.credentials" class="org.apache.ignite.plugin.security.SecurityCredentials">
    <constructor-arg value="web-agent"/>
    <constructor-arg value="12345"/>
</bean>

<!-- Ignite configuration. -->
<bean id="grid.cfg.base" abstract="true" class="org.apache.ignite.configuration.IgniteConfiguration">

    <!-- Other Configurations -->
    ...
</bean>

<bean parent="grid.cfg.base">
    <property name="pluginConfigurations">
        <list>
            <bean class="org.gridgain.grid.configuration.GridGainConfiguration">
                <!-- Set up authentication -->
                <property name="authenticator">
                    <bean class="org.gridgain.grid.security.passcode.PasscodeAuthenticator">
                        <property name="aclProvider">
                            <bean class="org.gridgain.grid.security.passcode.AuthenticationAclBasicProvider">
                                <constructor-arg>
                                    <map>
                                        <!-- Allow all operations on data nodes. -->
                                        <entry key-ref="node.credentials" value="{defaultAllow:true}"/>

                                        <!-- Permissions for the Web Console user. -->
                                        <entry key-ref="web-console-user.credentials" value="{
                                              defaultAllow:false,
                                              {
                                                  system:[ADMIN_VIEW, ADMIN_OPS]
                                              }
                                        }"/>

                                        <!-- Permissions for the Web Agent. -->
                                        <entry key-ref="web-agent.credentials" value="{defaultAllow:false}"/>
                                    </map>
                                </constructor-arg>
                            </bean>
                        </property>
                    </bean>
                </property>

                <property name="securityCredentialsProvider">
                    <bean class="org.apache.ignite.plugin.security.SecurityCredentialsBasicProvider">
                        <constructor-arg ref="node.credentials"/>
                    </bean>
                </property>
            </bean>
        </list>
    </property>
</bean>

Start the cluster using a configuration file that has security configured (like the one shown in the example above).
From your GridGain Web Agent directory, open the default.properties file and uncomment the node-login and node-password properties. Provide the values corresponding to the Web Agent security credentials set in the XML configuration file. For this example these values will be:
node-login=web-agent node-password=12345
In the terminal, start the Web Agent from the GridGain Web Agent directory using the web-console-agent.[sh|bat] script.
Login to your locally deployed web console instance.

You can also try the already deployed GridGain Web Console instance.
On the Web Console’s Monitoring tab, click on any page that tries to access the cluster, for example, Dashboard. The Cluster Authentication dialog appears. Enter the Web Console credentials as mentioned in the XML configuration file. Note that this dialog appears for any page that tries to access the cluster.

Once authenticated, the web console can interact with the cluster.

Credentials of the user in the Web Console and GridGain can match, but they don’t have to. Different sets of users can be set up for the Web Console and for the cluster.

Every command sent from the Web Console to the cluster passes through an authentication procedure. Either the provided username and password or a session token from a previous invocation is used. Session tokens are valid for a limited amount of time. The timeout can be set up in the REST API configuration on the cluster’s side.

User Permissions

Users in GridGain can have certain limitations on the set of operations that they are allowed to perform. For example, it’s possible to forbid certain users to create caches or modify data. A full set of permissions and instructions for their configuration can be found in the Authorization and Permissions section of the GridGain documentation.

Web Console users require additional permissions to be able to work with the cluster. In addition to regular security checks, operations triggered by Web Console users need to pass checks for ADMIN_* permissions. Depending on the role of the user, they can be granted the ADMIN_VIEW, ADMIN_OPS, ADMIN_QUERY or ADMIN_CACHE permissions.

ADMIN_VIEW provides read access to all information about the cluster to Web Console users. No modifications to the cluster state or configuration are managed by this permission. Data access is also not covered by the ADMIN_VIEW permission.

ADMIN_OPS allows Web Console users make changes to the cluster’s state and configuration. Here is the list of the operations that the ADMIN_OPS permission allows:

changing the cluster’s state (activation, deactivation);
changing the baseline topology;
updating the cluster’s license;
starting and stopping of the datacenter replication and triggering the full state transfer;
triggering garbage collection on nodes;
resetting metrics;
performing actions on snapshots (creating, restoring, moving, copying, removing, managing snapshot schedules);
cancelling running SQL queries.

ADMIN_QUERY is required to run SQL queries on the cluster from Web Console. Note that most queries will require additional cluster permissions like CACHE_READ or GET_QUERY_VIEWS.

ADMIN_CACHE allows users to perform actions related to caches. Here is the list of such operations:

enabling or disabling cache metrics;
creating and destroying caches (CACHE_CREATE and CACHE_DESTROY are required);
clearing caches;
loading data from a cache store;
resetting cache metrics;
triggering rebalance;
retrieving values (CACHE_READ is also required for it).

Note, that ADMIN_* permissions only work for Web Console and control.sh users and for so-called internal Visor tasks. Operations triggered via Java API, thin clients or via other API don’t require ADMIN_* permissions.

© 2024 GridGain Systems, Inc. All Rights Reserved. Privacy Policy | Legal Notices. GridGain® is a registered trademark of GridGain Systems, Inc.
Apache, Apache Ignite, the Apache feather and the Apache Ignite logo are either registered trademarks or trademarks of The Apache Software Foundation.

Last updated on Jan 26, 2024