Geode is introducing additional security features which allow finer grained control for JMX operations as well as GFSH commands. This functionality is automatically activated when the Geode properties security-client-authenticator and security-client-accessor are set.

Permissions are designed to be noun-verby and are in the form of RESOURCE:OPERATION[:REGION] tuples. The following values are valid:

Resource

• CLUSTER
• DATA

Operation

• MANAGE
• READ
• WRITE

At the end of this document is a reference list of all JMX and GFSH operations with their corresponding permissions.

To quickly get started using permissions for JMX and GFSH a sample implementation of com.gemstone.gemfire.security.Authenticator and com.gemstone.gemfire.security.AccessControl is provided by the class com.gemstone.gemfire.security.templates.SampleJsonAuthorization. This implementation requires a JSON file which defines the allowed users and their corresponding permissions. For example:

{
  "roles": [
    {
      "name": "cluster",
      "operationsAllowed": [
        "CLUSTER:MANAGE",
        "CLUSTER:WRITE",
        "CLUSTER:READ"
      ]
    },
    {
      "name": "data",
      "operationsAllowed": [
        "DATA:MANAGE",
        "DATA:WRITE",
        "DATA:READ"
      ],
      "regions": ["region1", "region2"]
    }
  ]
  "users": [
    {
      "name": "super-user",
      "password": "1234567",
      "roles": [
        "cluster",
        "data"
      ]
    },
    {
      "name": "joebloggs",
      "password": "1234567",
      "roles": [
        "data"
      ]
    }
  ]
}

In this example we have two roles defined: cluster and data. The data role only has access to two regions: region1 and region2.

To start using this sample perform the following steps:

1. Using gfsh, start a locator with security activated.

   gfsh> start locator --name=locator1 \
       --J=-Dgemfire.security-client-authenticator=com.gemstone.gemfire.security.templates.SampleJsonAuthorization.create \
       --J=-Dgemfire.security-client-accessor=com.gemstone.gemfire.security.templates.SampleJsonAuthorization.create

2. Similarly, start a server

   gfsh> start server --name=server1 --locators=localhost[10334]

3. Start a new instance of gfsh and connect with one of the users defined in your JSON file. The super-user should be allowed to do everything in gfsh.

   gfsh> connect --locators=localhost[10334] --user=super-user --password=1234567

4. Disconnect and reconnect with a user with lesser privileges:

   gfsh> disconnect
   gfsh> connect --locators=localhost[10334] --user=joebloggs --password=1234567
   gfsh> stop server --name=server1
   An error occurred while attempting to stop a Cache Server: Subject does not have permission [CLUSTER:READ]
    

Client-Server Security

You may notice that this new functionality is activated in the same way that the existing client-server authentication and authorization is activated. The intention is that eventually all means of accessing Geode will be secured with exactly the same callbacks.

If you already have an existing implementation of Authenticator and AccessControl no changes to existing code should be necessary. However, you should be aware of the following:

• All Resources are enumerated via the enum OperationContext.Resource.
• All OperationCodes are enumerated via the enum OperationContext.OperationCode.
• All of the existing OperationContext.is* methods have been deprecated in favor of testing against the relevant enums.
• The resource and operation code, for a given context, can be retrieved using OperationContext.getResource and OperationContext.getOperationCode respectively.

• Existing code, implementing AccessControl, would have needed to check the type of the OperationContext as passed into the authorizeOperation method. This is still possible, however it will now be easier to achieve the same functionality by simply checking the Resource and OperationCode of the context. For example, existing code might have looked like this:

    @Override
    public boolean authorizeOperation(String regionName, OperationContext context) {
      if (context instanceof PutOperationContext) {
        // cast to PutOperationContext
      } else if (context instanceof QueryOperationContext) {
        // cast to QueryOperationContext
      } else {
        // Must be JMX or CLI
      }
      return false;
    }

  Can now be changed to:

  @Override
  public boolean authorizeOperation(String regionName, OperationContext context) {
    switch (context.getOperationCode()) {
      case PUT:
        // cast to PutOperationContext
        break;
      case QUERY:
        // cast to QueryOperationContext
        break;
      default:
        // Must be JMX or CLI
    }
    return false;
  }

  Note that any JMX or CLI contexts are not associated with a specific type of OperationContext and are handled as 'default' cases.

• All client-server operations are associated with a Resource of DATA.

Reference

Client-Server

Client-server permissions are associated with their respective OperationContexts as follows. Permissions appear as Resource:OperationCode tuples.

GFSH and JMX

Following are lists for gfsh commands, (highlighted in green), and JMX operations with their corresponding permissions. Permissions appear as Resource:OperationCode tuples.

• Page:
  Releasing Apache Geode
• Page:
  Running a Geode cluster in docker
• Page:
  Adding REST Cluster Management Operations
• Page:
  Creating a persistent cache service
• Page:
  Publishing Geode Metrics to External Monitoring Systems