Cette autorisation est globale et permet à la fois de créer de nouveaux index et de modifier des index existants.
logs_write_exclusion_filters
Permet à un rôle de créer et de modifier des filtres d’exclusion dans un index.
Cette autorisation peut être globale ou limitée à un sous-ensemble d’index.
Sous-ensemble d’index :
Supprimez l’autorisation globale accordée au rôle.
Accordez cette autorisation au rôle depuis la page Index du site Datadog en modifiant un index et en ajoutant le rôle dans le champ « Grant editing Exclusion Filters of this index to » (voir la capture d’écran ci-dessous).
Cette configuration est uniquement prise en charge via l’interface utilisateur.
Cette autorisation est globale et permet à la fois de créer de nouvelles archives et de modifier ou de supprimer les archives existantes.
logs_read_archives
Permet à un rôle d’accéder aux informations de configuration des archives. Utilisée conjointement avec Logs Write Historical Views, cette autorisation permet également de déclencher une réintégration à partir des archives.
Cette autorisation peut être limitée à un sous-ensemble d’archives. Une archive sans restriction est accessible par toute personne disposant d’un rôle et de l’autorisation logs_read_archives. Une archive présentant des restrictions est uniquement accessible aux utilisateurs possédant un des rôles enregistrés, à condition que ces rôles disposent de l’autorisation logs_read_archives.
Dans l’exemple suivant, en supposant que tous les rôles à l’exception de Guest disposent de l’autorisation logs_read_archive :
L’archive Staging est accessible à tous les utilisateurs, à l’exception des utilisateurs ayant uniquement le rôle Guest.
L’archive Prod est accessible à tous les utilisateurs ayant le rôle Customer Support.
L’archive Security-Audit n’est pas accessible aux utilisateurs ayant le rôle Customer Support, sauf s’ils ont également le rôle Audit & Security.
Créez une archive ou mettez une archive existante à jour en la modifiant.
Utilisez l’API Logs Archives pour attribuer ou révoquer un rôle pour une archive donnée.
logs_write_historical_views
Permet à un rôle d’écrire des vues historiques, c’est-à-dire d’utiliser la fonctionnalité Log Rehydration*.
Cette autorisation est globale et permet aux utilisateurs de lancer une réintégration à partir d’archives pour lesquelles ils disposent de l’autorisation Logs_Read_Archives.
Dans l’exemple ci-dessus :
Les membres ayant le rôle ADMINpeuvent lancer une réintégration à partir de l’archive Audit, car ils disposent de l’autorisation logs_write_historical_view ainsi que de l’autorisation logs_read_archives pour cette archive.
Les membres ayant le rôle AUDIT ne peuvent pas lancer de réintégration à partir de l’archive Audit, car ils ne disposent pas de l’autorisation logs_historical_view.
Les membres ayant le rôle PROD ne peuvent pas lancer de réintégration à partir de l’archive Audit, car ils ne disposent pas de l’autorisation logs_read_archives.
Lors de l’attribution de tags team:audit à tous les logs réintégrés à partir de l’archive Audit, assurez-vous que les membres avec le rôle Audit qui sont limités à la lecture des logs team:audit ne peuvent accéder qu’au contenu réintégré. Pour en savoir plus sur l’ajout de tags et la réintégration, consultez la section relative à la configuration des archives de logs.
Pour les logs service:ci-cd réintégrés à partir de l’archive Prod, notez ce qui suit :
Si vous n’utilisez pas l’ancienne autorisation Logs Read Index Data, ces logs sont accessibles aux membres ayant le rôle CI-CD.
Si vous utilisez l’ancienne autorisation Logs Read Index Data, ces logs ne sont pas accessibles aux membres ayant le rôle CI-CD, car l’accès à la vue historique qui en résulte est limité aux membres ayant le rôle PROD ou ADMIN.
Autorisation retirée : logs_public_config_api
Datadog a retiré l’autorisation logs_public_config_api.
Cinq autorisations distinctes permettent désormais de consulter, créer ou modifier une configuration de log via l’API Datadog :
Accordez les autorisations suivantes pour gérer l’accès en lecture à des sous-ensembles de données de log :
Logs Read Data (conseillé) : offre un contrôle plus précis. Vous pouvez restreindre l’accès d’un rôle aux logs correspondant à des requêtes de restriction de logs.
Logs Read Index Data : autorisation anciennement utilisée pour restreindre l’accès aux données de log d’index spécifiques (cette autorisation reste nécessaire pour accéder aux données indexées).
logs_read_data
Accès en lecture aux données de log. Si cette autorisation est accordée, d’autres restrictions peuvent être appliquées telles que logs_read_index_data ou via une requête de restriction.
Les rôles sont cumulatifs : si un utilisateur dispose de plusieurs rôles, toutes les autorisations de chacun des rôles déterminent les données auxquelles il a accès.
Exemple :
Si un utilisateur dispose d’un rôle avec un accès en lecture aux données de logs ainsi que d’un rôle sans accès en lecture aux données de logs, alors il peut lire les données.
Si un utilisateur est limité à service:sandbox par un rôle, et qu’il est limité à env:prod par un autre rôle, alors l’utilisateur peut accéder à tous les logs de env:prod et service:sandbox.
Pour limiter les utilisateurs de manière à ce qu’ils puissent voir uniquement les logs correspondant à une requête de restriction, accédez à la page Data Access :
Assignez un ou plusieurs rôles à cette requête de restriction.
Vérifiez quels rôles et utilisateurs sont assignés aux requêtes de restriction.
Cette vue répertorie les éléments suivants :
Section Restricted Access : toutes les requêtes de restriction, ainsi que le ou les rôles associés.
Section Unrestricted Access : tous les rôles qui disposent de l’autorisation log_read_data sans restriction supplémentaire.
Section No Access : tous les rôles qui ne disposent pas de l’autorisation log_read_data.
Créer une requête de restriction
Créez une requête de restriction en définissant son filtre de requête. La nouvelle requête apparaît dans la liste des restrictions sans aucun rôle associé.
Assigner un rôle à une requête de restriction
Choisissez un rôle et assignez-le à la requête de restriction de votre choix.
Remarque : n’oubliez pas qu’un rôle peut être assigné à une seule requête de restriction. Lorsque c’est le cas, le rôle perd tout lien avec la requête de restriction qui lui était auparavant assignée.
De la même manière, utilisez cette action de déplacement pour accorder un Unrestricted Access à un rôle ou, à l’inverse, pour le transformer en rôle de type No Access.
Vérifier les requêtes de restriction
La page Data Access affiche jusqu’à 50 requêtes de restriction et 50 rôles par section. Si vous disposez d’un plus grand nombre de requêtes de restriction et rôles, appliquez des filtres à la vue :
À l’aide du filtre de requête de restriction :
À l’aide du filtre de rôle :
À l’aide du filtre d’utilisateur, qui vous permet de visualiser facilement le contenu auquel peut accéder un utilisateur spécifique associé à plusieurs rôles :
Révoquez ou accordez cette autorisation avec l’API Rôles. Utilisez des requêtes de restriction pour restreindre l’autorisation à un sous-ensemble de données de log.
Autorisations héritées
Ces autorisations sont activées globalement par défaut pour tous les utilisateurs.
L’autorisation Logs Read Data vient s’ajouter à ces autorisations obsolètes. Par exemple, imaginons qu’un utilisateur est limité à la requête service:api.
Si cet utilisateur filtre l’autorisation Read Index Data sur les index audit et errors, il voit uniquement les logs service:api dans ces index.
Si cet utilisateur dispose de l’autorisation Live tail, il voit uniquement les logs service:api dans le Live tail.
logs_read_index_data
Permet à un rôle de lire des index de logs. L’accès peut être accordé globalement ou limité à un sous-ensemble d’index de logs.
Pour limiter cette autorisation à un sous-ensemble d’index, supprimez d’abord les autorisations logs_read_index_data et logs_modify_indexes du rôle. Suivez ensuite les étapes suivantes :
