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.
and 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 blah.blah.ExampleJSONAuthorization
org.apache.geode.examples.security.ExampleSecurityManager
. 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" ] |
...
} |
...
] |
...
}
Step-by-step guide
Reference
Following are lists for gfsh commands, (highlighted in green), and JMX operations with their corresponding permissions.
...
...
...
} |
In this 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-manager=org.apache.geode.examples.security.ExampleSecurityManager --classpath=.
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.
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 --locator=localhost[10334] --user=super-user --password=1234567
Disconnect and reconnect with a user with lesser privileges:
Code Block gfsh> disconnect gfsh> connect --locator=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]
- Currently, changes to the security.json file require the locator to be restarted.
...
Content by Label | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...