Security and Audit
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 plug 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 following: data altering operations, 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 the 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 the Web Console monitoring and management tool as well.
Should an undesired event occur, 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 the authenticated subject username. This ensures that every event has information about the party responsible for the event.
In addition to the username, every event also contains the responsible party IP address, cluster member IP address, and affected data before and after the change.
In cases 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 the
Event StorageSPI. This SPI provides a pluggable mechanism for users to log events in any desired format to any underlying storage system, whether that’s 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.
See Auditing and Events for more information about how to set up auditing via events.