Създаване на контрол на достъп, базиран на роли в MongoDB

MongoDB предоставя потребителски достъп чрез контроли, базирани на роли, включително много вградени роли, които могат да бъдат присвоени на потребителите. Двете най-известни контроли са ролите за четене и четене/запис, но понякога те не са толкова детайлни, колкото бихме искали да бъдат.

Наскоро имах възможност да проуча дефинираните от потребителя роли във въведените във версия MongoDB 2.6. В тази статия ще разгледаме дефинираните от потребителя роли в MongoDB и ще дефинираме някои персонализирани роли, които може да ви бъдат полезни.

1. Създаване на роли в MongoDB

   Създаването на дефинирана от потребителя роля в MongoDB е доста просто. Можете да използвате команда createRole, за да създадете нова роля, а общият синтаксис за създаване на роля е както следва:

   
   {
      createRole: "<role name>",
      privileges: [{
         resource: { <resource> },
         actions: [ "<action>",] },
      ],
      roles: [
         { role: "<role>", db: "<database>" } | "<role>",],
      writeConcern: <write concern document>
   }
   
   

   Преди да изпълните командата createRole, уверете се, че сте превключили към базата данни, в която искате да създадете ролята, тъй като те ще бъдат дефинирани в базата данни само в които са създадени. Ако искате да създадете роля, която предоставя достъп до повече от една база данни, тогава тя трябва да бъде създадена в администраторската база данни.

   Нека разгледаме основните компоненти на синтаксиса за създаване на роля.

2. Привилегии на роля

   Създайте разрешения за дефинирана от потребителя роля чрез добавяне на привилегия и дефиниране на вашите действия и ресурси:

   Действия за привилегии

   Действията са набор от операции, които са групирани заедно, като например действието вмъкване, което може да изпълнява както вмъкване, така и създаване. Действията са толкова детайлни, колкото получава базираният на роли контрол на достъпа на MongoDB. Параметърът privileges може да се използва за добавяне на роли към mongo действия, а привилегията съставлява действията заедно с ресурса, към който се прилага. Използвайте следното, за да добавите действията за намиране, вмъкване и актуализиране в базата данни “mydb”.

   
   privileges:
   [
      {resource: {db: "mydb", collection: "" },
      actions: [ “find”,”insert”,”update” ] }
   ]
   
   

   Ресурси за привилегии

   Ресурсният документ указва обхвата, на който ще се прилагат действията ви за привилегии, и може да бъде зададен с различни детайли, както следва:

   a. Колекция

   Ресурсът може да бъде настроен на ресурс:{db: "<db-name>", collection: "<collection name>" } да предоставите посочените действия на само тази конкретна колекция.

   b. База данни

   Ресурсът може да бъде зададен на конкретна база данни, като параметърът за колекция се остави празен. Ресурс на низ за ресурс:{db: "<db-name>", collection: "<collection name>" } задава обхвата на цялата база данни.

   c. Единична колекция в бази данни

   Ресурсът може да бъде зададен на конкретна колекция с помощта на ресурс:{db: ", collection: "<collection name>" } за предоставяне на разрешения за колекцията във всички бази данни. Това разрешение може да се добави само към роля, създадена в администраторската база данни.

   d. Множество колекции в бази данни

   Ресурсът може да бъде зададен за всички колекции (с изключение на системните колекции) във всички бази данни, като оставите параметрите на db и на колекцията празен. ресурс:{db: "", collection: "" } . Този ресурс, подобно на горния, може да бъде предоставен само на роля, създадена в администраторската база данни.

   e. Ресурс за целия клъстер

   Ресурс за целия клъстер може да бъде посочен чрез използване на ресурс:{ cluster : true } . Този ресурс за целия клъстер се използва за уточняване на състоянието на системата, като изключване replSetReconfig вместо предоставяне на разрешения за конкретен документ.

   f. Всички ресурси

   Не се препоръчва използването на този обхват за нищо друго освен извънредни обстоятелства. {anyResource: true } може да се използва за задаване на обхват, зададен за всички ресурси.

3. Роли

   Вградените роли също могат да се добавят към персонализирана роля. Когато се добави вградена роля с помощта на параметъра roles:[], тя добавя разрешенията на вградената роля към персонализираната роля.

   Ето пример за параметъра role:

   
   roles: [{ role: "read", db: "<db name>"}]
   
   

   В този пример персонализираната роля ще наследи всички разрешения на ролята „четене“ върху дефинираната база данни. Ако роля е наследена в база данни db1, персонализираната роля може да бъде създадена в базата данни db1 или в администраторската база данни.

   Напишете загриженост

   Притеснението при записване определя нивото на потвърждение, поискано от MongoDB, и може да се използва за контрол на потвържденията за запис от базата данни. Имайте предвид, че при създаване на роля не се изисква загриженост за запис. Загрижеността за запис може да включва полета w, j и wtimeout:

   W  -  Притеснение за писане

   Поле W може да се използва за посочване на броя на случаите, до които записът е бил разпространен.

   J  -  Напишете загриженост

   Поле J може да бъде настроено, за да определи дали записът се записва в дневника.

   Wtimeout  -  Притеснение при писане

   Това се използва за задаване на времето, през което записът трябва да постигне загриженост за запис. Загрижеността за запис все още може да бъде постигната след извеждането на грешката. Ако Wtimeout не е зададен и проблемът за запис не може да бъде постигнат, записът ще бъде блокиран за неопределено време.

4. Присвояване на роли

   Персонализираните роли са специфични за db и могат да бъдат присвоени само на потребител в същата база данни.

   Да приемем, че създадохме роля „myrole“ в база данни „db1“. Можем да създадем потребител в базата данни с помощта на следните команди:

   
   Use db1
   
   db.createUser({"user" : "<user>",pwd: "<password>","roles" : [{"role" : "myrole", "db" : "db1"}]})
   
   

   За допълнителна информация относно управлението на потребителите вижте тази публикация от Dharshan относно управлението на потребителите в MongoDB.

5. Персонализирани потребителски роли

   Нека разгледаме някои персонализирани роли, които може да са полезни.

   Единична DB – Разрешения за четене, вмъкване и актуализиране

   Вградените роли read и readWrite може понякога да изглеждат като твърде много разрешения или твърде малко. Нека видим как можем да създадем персонализирана роля, предоставяща само разрешения за четене, вмъкване и запис.

   Вече знаем, че имаме нужда от всички разрешения за четене, за да можем да добавим вградената роля „read“ към нашата персонализирана роля. Също така се нуждаем от разрешения за създаване и актуализиране на документи и те могат да бъдат включени чрез добавяне на действия за вмъкване и актуализиране на привилегии. Ако искаме да дадем на потребителя възможността да създава индекс и да създава колекция, можем да добавим действието привилегия createIndex и createCollection.

   За обхвата, нека приемем, че имам db с име „db1“, на който зададох горните разрешения. Командата create ще изглежда така:

   
   Use db1.
   
   db.createRole(
   
   {
   
   createRole: "<role-name>",
   
   privileges: [
   
   { resource: { db: "db1", collection: "" },
   
   actions: [ "insert","update","createIndex", "createCollection" ] }
   
   ],
   
   roles: [{ role: "read", db: "db1"}]
   
   })
   
   

   Горената команда ще създаде роля с <role-name> в база данни db1. Потребител, на когото е предоставено разрешение от горната роля, няма да има действието привилегия „премахване“. Също така имайте предвид, че методите db.collection.findAndModify(),  db.collection.mapReduce() и  db.collection.aggregate() не могат да се изпълняват изцяло, тъй като изискват привилегията за премахване.

   Всички DB – Разрешения за четене, вмъкване и актуализиране

   Можем да създадем роля в администраторската база данни, която е подобна на тази по-горе, за да предоставим привилегии за четене, създаване и актуализиране на всички DB. Тази роля трябва да бъде създадена в администраторската БД и следващият потребител също трябва да бъде създаден в администраторската БД.

   За тази роля, вместо да използваме стандартната роля за четене, можем да наследим разрешения от ролята readAnyDatabase. Създаването на роля би изглеждало така:

   
   Use admin.
   
   db.createRole(
   
   {
   
   createRole: "<role-name>",
   
   privileges: [
   
   { resource: { db: "", collection: "" },
   
   actions: [ "insert","update","createIndex", "createCollection" ] }
   
   ],
   
   roles: [{ role: "readAnyDatabase", db: "admin"}]
   
   })
   
   

   Роли на писатели с притеснение при записване

   Ако имате сценарий, при който трябва да се наложи загриженост за запис, ето как може да се добави към роля. Добавянето на загриженост за запис към роля ще я наложи на всички потребители, предоставени под тази роля в DB. Нека дефинираме роля със загриженост за запис, която налага мнозинството записвания:

   
   Use admin.
   
   db.createRole(
   
   {
   
   createRole: "<role-name>",
   
   privileges: [ ],
   
   roles: [{ role: "readWriteAnyDatabase", db: "admin"}],
   
   writeConcern: { w: “majority”, j: false, wtimeout: 300 }
   
   })