Autorisations des rôles Datadog
Rapport de recherche Datadog : Bilan sur l'adoption de l'informatique sans serveur Rapport : Bilan sur l'adoption de l'informatique sans serveur

Autorisations des rôles Datadog

Une fois votre rôle créé, vous pouvez attribuer ou supprimer des autorisations pour ce rôle directement en le mettant à jour depuis l’application Datadog ou via l’API Permission de Datadog. Vous trouverez ci-dessous la liste des autorisations disponibles.

Présentation

Autorisations générales

Les autorisations générales définissent les niveaux d’accès minimum pour votre rôle. Les autorisations avancées permettent ensuite d’accorder des droits supplémentaires.

Nom de l’autorisationDescription
adminCette autorisation donne au rôle la possibilité de consulter et de modifier tous les éléments liés à votre organisation Datadog, sauf si une autorisation spécifique a été définie. Il s’agit notamment des informations de facturation et d’utilisation ainsi que des outils de gestion des utilisateurs, des clés, des rôles, des autorisations et de l’organisation. Cette autorisation inclut toutes les autorisations accordées par l’Accès standard.
standardCette autorisation donne au rôle la possibilité de consulter et modifier les composants de votre organisation Datadog, sauf si une autorisation spécifique a été définie. Il s’agit notamment de l’APM, des Événements ainsi que d’autres fonctionnalités qui ne concernent pas la gestion des comptes.

Remarque : il n’existe pas d’autorisation read-only étant donné qu’elle est définie par l’absence des autorisations admin et standard pour un rôle.

Autorisations avancées

Par défaut, les utilisateurs existants sont déjà associés à l’un des trois rôles Datadog par défaut : Admin, Standard ou Read-Only. Tous les utilisateurs sont donc déjà autorisés à lire l’ensemble des types de données. Les utilisateurs avec le rôle Admin ou Standard disposent quant à eux d’un droit d’écriture sur ces ressources.

Remarque : lorsque vous attribuez un nouveau rôle personnalisé à un utilisateur, assurez-vous de supprimer le rôle Datadog par défaut attribué à cet utilisateur afin d’appliquer les nouvelles autorisations de rôle.

En plus des autorisations générales, il est possible de définir des autorisations plus granulaires pour des ressources ou des types de données spécifiques. Les autorisations peuvent être globales ou limitées à un sous-ensemble d’éléments. Vous trouverez ci-dessous les détails de ces options et leur impact sur chacune des autorisations disponibles.

Gestion de l’accès

La liste ci-dessous répertorie les autorisations disponibles pour la gestion de l’accès :

NomDescriptionLimitation possible
user_access_manageAutorise la désactivation d’utilisateurs, la gestion des rôles d’utilisateur et les mappings SAML/rôle.non
user_access_invitePermet aux utilisateurs d’inviter d’autres utilisateurs à rejoindre l’organisation.non

Dashboards

La liste ci-dessous répertorie les autorisations disponibles pour les dashboards :

NomDescriptionLimitation possible
dashboards_readPossibilité de consulter les dashboardsfalse
dashboards_writePossibilité de créer et de modifier des dashboardsnon
dashboards_public_sharePossibilité de partager des dashboards en externenon

Monitors

La liste ci-dessous répertorie les autorisations disponibles pour les monitors :

NomDescriptionLimitation possible
monitors_readPossibilité de consulter les monitorsfalse
monitors_writePossibilité de modifier, désactiver et supprimer des monitorsfalse
monitors_downtimePossibilité de définir des downtimes pour vos monitorsfalse

Security Monitoring

La liste ci-dessous répertorie les autorisations disponibles pour les ressources Security Monitoring :

NomDescriptionLimitation possible
security_monitoring_rules_readPossibilité de consulter les règles de détectionfalse
security_monitoring_rules_writePossibilité de créer, modifier et supprimer des règles de détectionfalse
security_monitoring_signals_readPossibilité de consulter les signaux de sécuritéfalse

Log Management

Vous trouverez ci-dessous la liste des autorisations pour les ressources de configuration des logs et leurs données, ainsi qu’un profil type d’utilisateur auquel les autorisations sont généralement accordées. Pour obtenir des recommandations sur l’attribution d’autorisations à des membres d’équipe, consultez le guide sur le RBAC pour les logs.

NomDescriptionLimitation possibleUtilisateur type
logs_read_dataAccès en lecture aux données de logtrueLecture seule
logs_modify_indexesMise à jour de la définition des index de logsfalseAdmin
logs_write_facetsCréation, mise à jour et suppression de facettes de logfalseStandard
logs_write_exclusion_filtersMise à jour des filtres d’exclusion des indextrueStandard
logs_write_pipelinesMise à jour des pipelines de logsfalseAdmin
logs_write_processorsMise à jour des processeurs de logs d’un pipelinetrueStandard
logs_write_archivesMise à jour de la configuration des archives externesfalseAdmin
logs_read_archivesConsultation des détails de la configuration d’archives, accès au contenu à partir des archivestrueStandard
logs_write_historical_viewsRéintégration de données à partir des archivesfalseStandard
logs_public_config_apiAccès à l’API de configuration des logs publique (lecture/écriture)falseAdmin
logs_generate_metricsPossibilité de générer des métriquesfalseStandard

Le contrôle RBAC pour Log Management comprend également deux autorisations obsolètes, remplacées par une autorisation logs_read_data plus spécifique et plus étendue :

NomDescriptionLimitation possibleUtilisateur type
logs_live_tailAccès à la fonctionnalité Live TailfalseLecture seule
logs_read_index_dataLecture d’un sous-ensemble de données de log (par index)trueLecture seule

Une fois votre rôle créé, vous pouvez attribuer ou supprimer directement des autorisations pour ce rôle en le modifiant depuis l’application Datadog.

Une fois votre rôle créé, vous pouvez attribuer ou supprimer des autorisations pour ce rôle directement via l’API Permission de Datadog.

Vous trouverez plus de détails sur ces autorisations ci-dessous.

Accès à la configuration des logs

logs_generate_metrics

Permet à un rôle de générer des métriques.

Cette autorisation est globale et permet à la fois de créer de nouvelles métriques et de modifier ou de supprimer des métriques existantes.

logs_write_facets

Permet à un rôle de créer, modifier et supprimer des facettes.

Cette autorisation est globale et permet à la fois de créer de nouvelles facettes et de modifier ou de supprimer des facettes existantes.

Cette autorisation n’a aucune incidence sur la gestion des attributs standard ou des facettes utilisées pour les alias.

logs_modify_indexes

Permet à un rôle de créer et de modifier des index de logs, notamment en effectuant les actions suivantes :

Cette autorisation est globale et permet à la fois de créer de nouveaux index et de modifier des index existants.

Remarque : cette autorisation accorde également les autorisations logs_read_index_data et logs_write_exclusion_filters en arrière-plan.

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 :

  1. Supprimez l’autorisation globale accordée au rôle.
  2. Accordez cette autorisation au rôle depuis [la page Index de l’application Datadog][2] 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.

logs_write_pipelines

Permet à un rôle de créer et de modifier des pipelines de traitement de logs, notamment en effectuant les actions suivantes :

  • Définir le nom du pipeline
  • Définir des filtres des pipelines pour déterminer les logs qui doivent passer par le pipeline de traitement
  • Réorganiser les pipelines
  • Accorder l’autorisation logs_write_processors pour un pipeline spécifique à un autre rôle

Remarque : cette autorisation accorde également les autorisations Logs_Write_Processors (pour tous les processeurs sur tous les pipelines) en arrière-plan.

logs_write_processors

Permet à un rôle de créer, de modifier ou de supprimer des processeurs et des pipelines imbriqués.

Cette autorisation peut être globale ou limitée à un sous-ensemble de pipelines.

Accordez l’autorisation à un ou plusieurs rôles dans la fenêtre d’un pipeline spécifique.

Tout d’abord,

curl -X POST \
        https://app.datadoghq.com/api/v1/role/<RÔLE_UUID>/permission/<AUTORISATION_UUID> \
        -H "Content-Type: application/json" \
        -H "DD-API-KEY: <VOTRE_CLÉ_API_DATADOG>" \
        -H "DD-APPLICATION-KEY: <VOTRE_CLÉ_APPLICATION_DATADOG>" \
        -d '{
                "scope": {
                    "pipelines": [ "<ID_PIPELINE-X>", "<ID_PIPELINE-Y>"]
                }
            }'

logs_write_archives

Permet à un rôle de créer, de modifier ou de supprimer des archives de logs, notamment en effectuant les actions suivantes :

  • Configurer des filtres d’archives pour définir les logs qui doivent être ajoutés à une archive
  • Définir le nom de l’archive
  • Réorganiser les archives
  • Limiter l’autorisation logs_read_archives à un sous-ensemble de rôles.

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 d’accéder aux informations de configuration des archives. Utilisée en conjonction avec logs_write_historical_views, cette autorisation permet également de lancer 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_archive.

Dans l’exemple ci-dessus :

  • Les membres ayant le rôle ADMIN peuvent 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 ayant 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 dédiée à 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’autorisation obsolète logs_read_index_data, ces logs sont accessibles aux membres ayant le rôle CI-CD.
  • Si vous utilisez l’autorisation obsolète logs_read_index_data, ces logs ne sont pas accessibles aux membres ayant le rôle CI-CD, car la vue historique qui en résulte est limitée aux membres ayant le rôle PROD ou ADMIN.

logs_public_config_api

Permet de créer ou de modifier une configuration de log avec l’API Datadog :

L’autorisation logs_public_config_api accorde uniquement l’autorisation d’effectuer des actions par le biais de l’API. Par exemple, si un utilisateur ne dispose pas de l’autorisation logs_write_exclusion_filter, il ne pourra pas mettre à jour le taux d’échantillonnage via l’API, et ce même s’il dispose de l’autorisation logs_public_config_api.

Accès aux données de log

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 une granularité supérieure en permettant de 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, utilisez la page Data Access dans l’application Datadog pour :

  1. Créer une requête de restriction.
  2. Assigner un ou plusieurs rôles à cette requête de restriction.
  3. Vérifier 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é.

Créer une requête de restriction
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 associé à une seule requête de restriction. Par conséquent, si vous assignez un rôle à une requête de restriction, il perd tout lien avec la requête de restriction à laquelle il était déjà associé.

Assigner un rôle à une requête de restriction

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

Cette page affiche un maximum de 50 requêtes de restriction à la fois et de 50 rôles par section. Si vous avez des centaines ou des milliers de rôles et de requêtes de restriction, utilisez les filtres pour affiner 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 Roles. 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 dispose de l’autorisation logs_read_index_data pour les index audit et errors uniquement, il verra uniquement les logs service:api dans ces index.
  • Si cet utilisateur dispose de l’autorisation logs_live_tail, il verra 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. Ensuite :

Accordez à ce rôle l’accès à l’index depuis la page de configuration.

curl -X POST \
        https://app.datadoghq.com/api/v1/role/<RÔLE_UUID>/permission/<AUTORISATION_UUID> \
        -H "Content-Type: application/json" \
        -H "DD-API-KEY: <VOTRE_CLÉ_API_DATADOG>" \
        -H "DD-APPLICATION-KEY: <VOTRE_CLÉ_APPLICATION_DATADOG>" \
        -d '{
                "scope": {
                    "indexes": ["<ID_INDEX-1>",["<ID_INDEX-2>"]
                }
            }'

logs_live_tail

Permet à un rôle d’utiliser la fonctionnalité Live Tail.

Cette autorisation est globale et accorde l’accès à la fonction Livetail indépendamment de l’autorisation logs_read_index_data.

Pour aller plus loin


*Log Rehydration est une marque déposée de Datadog, Inc.