Prod permissions

[sebmr2]

Description

Trying to prevent the CRUD service from having the dropCollection permission. When using the CRUD service to create views, it tries a drop and then creates the view as if it was always altering an existing view, My initial thought is I could elevate the accounts access and then remove post deploy. Will anything break if the service account has dropCollection removed? Is there a way to skip certain objects and generate a script for them?

[danibix95]

Hi @sebmr2, I created a MongoDB custom role with limited privileges, so that I could test CRUD Service behavior. I observed that dropCollection privilege action is not needed by CRUD Service to create MongoDB views. In fact, all the functionalities seemed to continue working as intended. Consequently, you should not need to add and then remove such permission from your Mongo user in order to operate CRUD Service.

Nonetheless, CRUD Service prints out a log every time an action it wants to perform cannot be performed due to insufficient privileges. These log state which command cannot be executed, easing the selection of which privilege actions should be applied. Therefore, you may further try experimenting with user privileges and observe which ones allows the service to work properly.

In the image below it can be seen which privilege actions where assigned to the custom role assigned to the Mongo user employed for the test I carried out.

[sebmr2]

My default user would normally have read, insert, update, and remove

[danibix95]

You're right. I updated the permissions list as follows, removing built-in roles:

find                        (all collections)
insert                      (all collections)
remove                      (all collections)
update                      (all collections)
createCollection            (all collections)
createIndex                 (all collections)
collMod                     (all collections)
dropIndex                   (all collections)
reIndex                     (all collections)
listIndexes                 (all collections)
bypassDocumentValidation    (all collections)
changeStream                (all collections)
validate                    (all collections)
listCollections             (all collections)

and experienced the mentioned startup problem when removing the dropCollection privilege.

In order to avoid requesting such permission, I updated the code to rather modify a view instead of dropping it, as it is shown here. The change has been introduced with this PR and it can be tried out with latest tag main of CRUD Service.

[dallas-fletchall]

Thanks for all the hard work!

I hate to ask for more, but is it possible to get a release candidate that includes this PR?

.

We can build locally and perform some testing, but would feel more comfortable knowing that this will work in our environment if we could pull from a registry already setup in the cluster.

[danibix95]

Hi, you can now try out the RC version 7.2.3-rc.0 of CRUD Service.

Let us know whether it works as expected.

[galatifederico]

Hi @dallas-fletchall, can you confirm that the version 7.2.3-rc.0 works as expected?
In that case we can proceed to create a tag with the new feature.

Thanks

[sebmr2]

Looks like everything is working. Much happier granting collMod vs dropCollection 😄

[dallas-fletchall]

Agree, tested with 7.2.3-rc.1, with success.

[danibix95]

Hi! Thank you for your feedback. These changes will land soon in a new stable release

[danibix95]

Hi! New stable version v7.2.3 of CRUD Service is now available.