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 permissionsand Pulse. Additional information can be found here: Geode Integrated Security.
To quickly get started using permissions for JMX and GFSH a sample implementation of comof org.gemstoneapache.gemfiregeode.security.Authenticator and com.gemstone.gemfire.security.AccessControl
is SecurityManager is provided by the class comorg.apache.gemstonegeode.gemfireexamples.security.examplesExampleSecurityManager
. SampleJsonAuthorization. This implementation requires a JSON file which defines the allowed users and their corresponding permissions. For example:
Code Block |
---|
{ "roles": [ { "name": "cluster", "operationsAllowed": [ "CLUSTER:MANAGE", "CLUSTER:WRITE", "CLUSTER:READ" ] }, { "name": "data", "operationsAllowed": [ "DATA:MANAGE", "DATA:WRITE", "DATA:READ" ] }, { "name": "region1&2Reader", "operationsAllowed": [ "DATA:READ" ], "regions": ["region1", "region2"] } ], "users": [ { "name": "super-user", "password": "1234567", "roles": [ "cluster", "data" ] }, { "name": "joebloggs", "password": "1234567", "roles": [ "data" ] } ] } |
In this example sample "security.json" file, we have two roles defined: cluster and data. The cluster role can perform cluster level operations like list members, whereas the data role can access/store data in Regions. The data role only has access to two regions: region1 and region2.
To start using this sample perform the following steps:
Copy the above "security.json" file into locator's and server's directory (locator1 and server1 in the example below).
Using gfsh, start a locator with security activated. In the example below, we disable peer-to-peer security for simplicity of configuration
Code Block language bash gfsh> start locator --name=locator1 \ --J=-Dgemfire.security-client-authenticatormanager=comorg.gemstoneapache.gemfire.securitygeode.examples.SampleJsonAuthorizationsecurity.create \ ExampleSecurityManager --J=-Dgemfire.security-client-accessor=com.gemstone.gemfire.security.examples.SampleJsonAuthorization.createclasspath=.
Similarly, start a server (you will need to provide user/password in order to join the cluster. The user needs to have cluster:manage privilege). Notice server is started with a security-manager, but since locator's cluster configuration is enabled, the security-manager setting will be distributed to the server automatically. This ensures that the entire cluster is using the same security-manager.
Similarly, start a server
Code Block gfsh> start server --name=server1 --locators=localhost[10334] \ --classpath=. \ --user=super-user --password=1234567
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.
Code Block gfsh> connect --locatorslocator=localhost[10334] --user=super-user --password=1234567
Disconnect and reconnect with a user with lesser privileges:
Code Block gfsh> disconnect gfsh> connect --locatorslocator=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
andOperationContext.getOperationCode
respectively.
This means that Resources and Operation(Codes) extend to client-server security too. For client-server the only resource is DATA.
Reference
Following are lists for gfsh commands, (highlighted in green), and JMX operations with their corresponding permissions.
...
...
...
- Currently, changes to the security.json file require the locator to be restarted.
...
Content by Label | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...