Unlike a single instance MongoDB setup or even a ReplicaSet one, when it gets to a Sharded installation, things may get thougher.
For example, if you gave a user a reading permissions to use MongoChef (a most recommended MongoDB client), when it comes to a clustered intallation, in order to avoid the "not authorized to run inprog" error when running db.currentOp(), you should provide the user with some more permissions (in this case the inprog permissions).
Actually it is pretty simple, but it is also a good example for a secured environment management:
Providing inprog Permissions
1. Get to the admin database
use admin;
2. Authorize as a permitted user
db.auth("admin","admin_password");
3. Create a new role that will have permissions to manage the processes
db.createRole(
{
role: "manageOpRole",
privileges: [
{
resource: { cluster: true },
actions: [ "killop", "inprog" ]
},
{
resource: { db: "", collection: "" },
actions: [ "killCursors" ]
}
],
roles: []
}
);
4. Provide the permissions to the user:
db.grantRolesToUser(
"reading",
[
{ role: "manageOpRole", db: "admin" }
]
);
5. Authenticate as the reading user
db.auth("reading","reading_password");
6. Verify things actually work! (or doing the definition of done);
db.currentOp()
Bottom Line
Simple, tested and secured like we always love our environments!
Keep Performing,
Moshe Kaplan
