Création d'un contrôle d'accès basé sur les rôles dans MongoDB

MongoDB fournit un accès utilisateur via des contrôles basés sur les rôles, y compris de nombreux rôles intégrés pouvant être attribués aux utilisateurs. Les deux contrôles les plus connus sont les rôles de lecture et de lecture/écriture, mais parfois, ils ne sont pas aussi précis que nous le souhaiterions.

J'ai récemment eu l'occasion d'explorer les rôles définis par l'utilisateur introduits dans MongoDB version 2.6. Dans cet article, nous allons passer en revue les rôles MongoDB définis par l'utilisateur et définir certains rôles personnalisés qui pourraient vous être utiles.

1. Créer des rôles dans MongoDB

   Créer un rôle défini par l'utilisateur dans MongoDB est assez simple. Vous pouvez utiliser la commande createRole pour créer un nouveau rôle, et la syntaxe générique de création de rôle est la suivante :

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

   Avant d'exécuter la commande createRole, assurez-vous de basculer vers la base de données dans laquelle vous souhaitez créer le rôle, car ils ne seront définis que dans la base de données dans laquelle ils ont été créés. Si vous souhaitez créer un rôle qui accorde l'accès à plusieurs bases de données, vous devez le créer dans la base de données d'administration.

   Passons en revue les principaux composants de la syntaxe de création de rôle.

2. Privilèges de rôle

   Créez des autorisations pour un rôle défini par l'utilisateur en ajoutant un privilège et en définissant vos actions et ressources :

   Actions de privilège

   Les actions sont un ensemble d'opérations qui sont regroupées, telles que l'action d'insertion qui peut effectuer à la fois l'insertion et la création. Les actions sont aussi granulaires que le contrôle d'accès basé sur les rôles de MongoDB. Le paramètre de privilèges peut être utilisé pour ajouter des rôles aux actions mongo, et un privilège constitue les actions avec la ressource à laquelle il s'applique. Utilisez ce qui suit pour ajouter les actions find, insert et update sur la base de données "mydb".

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

   Ressources sur les privilèges

   Le document de ressources spécifie la portée de vos actions de privilège qui s'appliqueront et peut être défini à différentes granularités comme suit :

   a. Collecte

   La ressource peut être définie sur ressource :{db: "<db-name>", collection: "<collection name>" } pour n'accorder les actions spécifiées qu'à cette collection particulière.

   b. Base de données

   La ressource peut être définie sur une base de données particulière en laissant le paramètre de collection vide. Ressource de chaîne de ressources :{db: "<db-name>", collection: "<collection name>" } définit la portée sur l'ensemble de la base de données.

   c. Collection unique dans toutes les bases de données

   La ressource peut être définie sur une collection particulière à l'aide de la ressource :{db: ", collection: "<collection name>" } pour accorder des autorisations à la collection sur toutes les bases de données. Cette autorisation ne peut être ajoutée qu'à un rôle créé dans la base de données d'administration.

   d. Collections multiples dans les bases de données

   La ressource peut être définie sur toutes les collections (à l'exception des collections système) dans toutes les bases de données en laissant les paramètres db et collection vider. ressource :{db: "", collection: "" } . Cette ressource, comme celle ci-dessus, ne peut être accordée qu'à un rôle créé sur la base de données d'administration.

   e. Ressource à l'échelle du cluster

   Une ressource à l'échelle du cluster peut être spécifiée à l'aide de ressource :{ cluster : true } . Cette ressource à l'échelle du cluster est utilisée pour spécifier l'état du système, comme l'arrêt de replSetReconfig plutôt que d'accorder des autorisations sur un document particulier.

   f. Toutes les ressources

   Il n'est pas recommandé d'utiliser cette étendue pour autre chose que des circonstances extraordinaires. {anyResource: true } peut être utilisé pour définir la portée sur toutes les ressources.

3. Rôles

   Les rôles intégrés peuvent également être ajoutés à un rôle personnalisé. Lorsqu'un rôle intégré est ajouté à l'aide du paramètre rôles :[], il ajoute les autorisations du rôle intégré au rôle personnalisé.

   Voici un exemple du paramètre rôles :

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

   Dans cet exemple, le rôle personnalisé hériterait de toutes les autorisations du rôle « lecture » ​​sur la base de données définie. Si un rôle est hérité sur une base de données db1, le rôle personnalisé peut être créé sur la base de données db1 ou sur la base de données admin.

   Écrire le problème

   Le problème d'écriture définit le niveau d'accusé de réception demandé à MongoDB et peut être utilisé pour contrôler les accusés de réception d'écriture à partir de la base de données. Notez qu'un problème d'écriture n'est pas requis lors de la création d'un rôle. Le problème d'écriture peut inclure les champs w, j et wtimeout :

   W  -  Écrire une préoccupation

   Le champ W peut être utilisé pour indiquer le nombre d'instances auxquelles l'écriture a été propagée.

   J -  Écrire une préoccupation

   Le champ J peut être défini pour déterminer si l'écriture est écrite dans le journal.

   Wtimeout  -  Écrire une préoccupation

   Ceci est utilisé pour définir le temps avant lequel l'écriture doit atteindre la préoccupation d'écriture. Le problème d'écriture peut toujours être atteint après la levée de l'erreur. Si un Wtimeout n'a pas été défini et que le problème d'écriture ne peut pas être atteint, l'écriture sera bloquée indéfiniment.

4. Attribuer des rôles

   Les rôles personnalisés sont spécifiques à la base de données et ne peuvent être attribués qu'à un utilisateur de la même base de données.

   Pour plus d'informations sur la gestion des utilisateurs, reportez-vous à cet article de Dharshan sur la gestion des utilisateurs dans MongoDB.

5. Rôles d'utilisateur personnalisés

   Passons en revue certains rôles personnalisés qui pourraient être utiles.

   Base de données unique – Autorisations de lecture, d'insertion et de mise à jour

   Les rôles intégrés read et readWrite peuvent parfois donner l'impression d'avoir trop ou trop peu d'autorisations. Voyons comment créer un rôle personnalisé accordant uniquement des autorisations de lecture, d'insertion et d'écriture.

   Nous savons déjà que nous avons besoin de toutes les autorisations de lecture afin de pouvoir ajouter le rôle intégré « lecture » ​​à notre rôle personnalisé. Nous avons également besoin d'autorisations pour créer et mettre à jour des documents, et celles-ci peuvent être incluses en ajoutant des actions de privilège d'insertion et de mise à jour. Si nous voulions donner à l'utilisateur la possibilité de créer un index et de créer une collection, nous pouvons ajouter l'action de privilège createIndex et createCollection.

   Pour la portée, supposons que j'ai une base de données nommée "db1" sur laquelle j'ai défini les autorisations ci-dessus. La commande de création ressemblerait à ceci :

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

   La commande ci-dessus créerait un rôle avec <role-name> dans la base de données db1. Un utilisateur qui a reçu l'autorisation par le rôle ci-dessus n'aura pas l'action de privilège "supprimer". Notez également que les méthodes db.collection.findAndModify(),  db.collection.mapReduce() et  db.collection.aggregate() ne peuvent pas être exécutées intégralement car elles nécessitent le privilège de suppression.

   Toutes les bases de données – Autorisations de lecture, d'insertion et de mise à jour

   Nous pouvons créer un rôle sur la base de données d'administration similaire à celui ci-dessus, pour accorder des privilèges de lecture, de création et de mise à jour sur toutes les bases de données. Ce rôle doit être créé sur la base de données d'administration et l'utilisateur suivant doit également être créé sur la base de données d'administration.

   Pour ce rôle, au lieu d'utiliser le rôle de lecture standard, nous pouvons hériter des autorisations du rôle readAnyDatabase. La création de rôle ressemblerait à ceci :

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

   Rôles de rédacteur avec préoccupation d'écriture

   Si vous avez un scénario où le problème d'écriture doit être appliqué, voici comment il peut être ajouté à un rôle. L'ajout d'un problème d'écriture à un rôle l'appliquerait à tous les utilisateurs accordés sous ce rôle sur la base de données. Définissons un rôle avec une préoccupation d'écriture qui applique les écritures majoritaires :

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