GridGain comes with a set of security features that enable Privileged Access for remote clients and other cluster members. This is accomplished by configuring pluggable authentication and authorization mechanisms, as well as providing full auditing capabilities that allow recreating any event in the system to be traced back to the user responsible for the event.
GridGain supports a pluggable
Authenticator allowing users to plugin any of their existing authentication mechanisms into GridGain. GridGain supports out of the box passcode-based and JAAS-based authentication. Through JAAS-based implementation, GridGain is able to automatically support JNDI, LDAP, Active Directory, and any other JAAS-compliant authentication and authorization mechanisms.
In order to authenticate, a client or a cluster member needs to provide a valid username and password, and if the authentication is successful, GridGain will retrieve a list of available permissions for the authenticated subject.
Once authenticated, a subject is given a preconfigured list of authorized permissions. GridGain allows permissions to be set for any of the data altering operation, closure or task execution, data querying and viewing, and administration and monitoring. The full list of all available permissions is defined by
SecurityPermission enumeration. Most permissions are set on a per-cache level, so the same user, as an example, may have READ and WRITE permissions for one cache and only QUERY permissions for another.
Authorization functionality is exposed to the user via
Security API in order to allow manual authorization checks from user code whenever custom logic is required.
All available security permissions can be set for Visor monitoring and management tool as well.
In the event that something undesired happened, it is important to be able to recreate what happened and trace it back to the authenticated subject responsible for the event. GridGain has multiple audit mechanisms ensuring that every event occurring in the system is traceable:
- Absolutely every event in the system contains authenticated subject username. This ensures that absolutely every event has information about the party responsible for the event.
- In addition to the username, every event also contains responsible party IP address, cluster member IP address, affected data before and after the change.
- In case where one event is caused by another event, the child event will have audit information about the parent event. For example, if a cache PUT operation was triggered from a closure or a task, then the cache PUT event will contain information about the parent TASK execution event, and so on.
- In addition to being able to trace all direct data access operations and queries, users can also trace indirect access as well. For example, if data has been accessed not from a server data node, but from a client-side near cache, or from a remote continuous query notification, it will still be logged as a separate event.
- Every event is recorded by
Event StorageSPI. This SPI provides a pluggable mechanism for users to log events in any desired format to any underlying storage system, be that a file system or any database.
- All data stored in cache contains metadata information about fields, so when printed out, all field names are listed together with values. This allows users to immediately tell which field has changed without tracing and correlating different logs.
Two ways to secure your cluster
Security can be configured in 2 ways - using GridGain Authentication and Authorization or Apache Ignite Authentication. However, GridGain security and Apache Ignite security are mutually exclusive; you can only use one or the other at a time. We recommend using GridGain security because it offers broader capabilities.