This section describes steps you can take to help you assess and configure the security of your environment in order to protect your VMware Tanzu GemFire cluster and your application from security intrusions.
The following security measures are strongly recommended for most applications:
Enable TLS between the application and the cluster, and between cluster members. Set ssl-components-enabled=all
and ssl-endpoint-identification-enabled=true
.
Implement and configure a security manager that can be adapted to your application’s security needs. For example, your security manager can establish Role-based Access Control (RBAC) and define a set of authorized resource permissions granted for users in those roles. See Security Implementation Introduction and Overview and Custom Security Manager Example for details.
Establish Firewall rules as needed to secure inbound and outbound communications for cluster members.
If using persistent regions, enable disk volume encryption in the Operating System. Consult your system’s OS documentation for implementation details.
Client applications are part of the trust boundary. Validate user input data and objects before writing to GemFire. See the OWASP Secure Coding Practices Input Validation Checklist for a list of recommended practices.
If you wish to further increase your security, then set validate-serializable-objects=true
to prevent deserialization of arbitrary Java objects within GemFire and add your classes to serializable-object-filter
.
When the SecurityManager
is enabled, by default GemFire throws a NotAuthorizedException
when a method
within a query is invoked and does not belong to the list of default allowed methods. The MethodInvocationAuthorizer
is used to determine whether a specific method invocation on a given object should be allowed or denied during the execution of a particular OQL query.
The default restrictions are strict but customizable. You can tighten or relax the default restrictions under particular circumstances using OQL method authorizers to determine whether a specific method invocation on a given object should be allowed or denied during the execution of an OQL query.
GemFire processes use TCP/IP ports to communicate with other processes or clients.
For example:
gfsh
and JConsole) can connect to JMX Managers and other manageable members on the pre-defined RMI port 1099. You can configure a different port if necessary.See Firewalls and Ports for the complete list of ports used by GemFire, their default values, and how to configure them if you do not want to use the default value.
These configuration files should be readable and writeable only by the dedicated user who runs servers:
gemfire.properties
cache.xml
gfsecurity.properties
A default gfsecurity.properties
is not provided in the defaultConfigs
directory. If you choose to use this properties file, you must create it manually. A clear text user name and associated clear text password may be in this file for authentication purposes. The file system’s access rights are relied upon to protect this sensitive information.The default location of the gemfire.properties
and cache.xml
configuration files is the defaultConfigs
child directory of the main installation directory.
By default, the log files are located in the working directory used when you started the corresponding processes.
For GemFire members (locators and cache servers), you can also specify a custom working directory location when you start each process. See Logging for more details.
The log files are as follows:
locator-name.log
: Contains logging information for the locator process.server-name.log
: Contains logging information for a cache server process.gfsh-%u_%g.log
: Contains logging information of an individual gfsh
environment and session.NoteBy default,
gfsh
session logging is activated. To enablegfsh
logging, you must set the Java system property-Dgfsh. log-level=desired_log_level
. See Configuring the gfsh Environment for more information.
These log files should be readable and writable only by the dedicated user that runs the servers.
Any security-related (properties that begin with security-*
) configuration properties that are normally configured in gemfire.properties
can be moved to a separate gfsecurity.properties
file. Placing these configuration settings in a separate file allows you to restrict access to security configuration data. This way, you can still allow read or write access for your gemfire.properties
file.
Upon startup, GemFire processes will look for the gfsecurity.properties
file in the following locations in order:
If any password-related security properties are listed in the file but have a blank value, the process will prompt the user to enter a password upon startup.