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.
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’autorisation | Description |
|---|---|
| admin | Cette 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. |
| standard | Cette 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.
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.
La liste ci-dessous répertorie les autorisations disponibles pour la gestion de l’accès :
| Nom | Description | Limitation possible |
|---|---|---|
user_access_manage | Autorise la désactivation d’utilisateurs, la gestion des rôles d’utilisateur et les mappings SAML/rôle. | non |
user_access_invite | Permet aux utilisateurs d’inviter d’autres utilisateurs à rejoindre l’organisation. | non |
La liste ci-dessous répertorie les autorisations disponibles pour les dashboards :
| Nom | Description | Limitation possible |
|---|---|---|
dashboards_read | Possibilité de consulter les dashboards | false |
dashboards_write | Possibilité de créer et de modifier des dashboards | non |
dashboards_public_share | Possibilité de partager des dashboards en externe | non |
La liste ci-dessous répertorie les autorisations disponibles pour les monitors :
| Nom | Description | Limitation possible |
|---|---|---|
monitors_read | Possibilité de consulter les monitors | false |
monitors_write | Possibilité de modifier, désactiver et supprimer des monitors | false |
monitors_downtime | Possibilité de définir des downtimes pour vos monitors | false |
La liste ci-dessous répertorie les autorisations disponibles pour les ressources Security Monitoring :
| Nom | Description | Limitation possible |
|---|---|---|
security_monitoring_rules_read | Possibilité de consulter les règles de détection | false |
security_monitoring_rules_write | Possibilité de créer, modifier et supprimer des règles de détection | false |
security_monitoring_signals_read | Possibilité de consulter les signaux de sécurité | false |
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.
| Nom | Description | Limitation possible | Utilisateur type |
|---|---|---|---|
logs_read_data | Accès en lecture aux données de log | true | Lecture seule |
logs_modify_indexes | Mise à jour de la définition des index de logs | false | Admin |
logs_write_facets | Création, mise à jour et suppression de facettes de log | false | Standard |
logs_write_exclusion_filters | Mise à jour des filtres d’exclusion des index | true | Standard |
logs_write_pipelines | Mise à jour des pipelines de logs | false | Admin |
logs_write_processors | Mise à jour des processeurs de logs d’un pipeline | true | Standard |
logs_write_archives | Mise à jour de la configuration des archives externes | false | Admin |
logs_read_archives | Consultation des détails de la configuration d’archives, accès au contenu à partir des archives | true | Standard |
logs_write_historical_views | Réintégration de données à partir des archives | false | Standard |
logs_public_config_api | Accès à l’API de configuration des logs publique (lecture/écriture) | false | Admin |
logs_generate_metrics | Possibilité de générer des métriques | false | Standard |
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 :
| Nom | Description | Limitation possible | Utilisateur type |
|---|---|---|---|
logs_live_tail | Accès à la fonctionnalité Live Tail | false | Lecture seule |
logs_read_index_data | Lecture d’un sous-ensemble de données de log (par index) | true | Lecture 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.
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.
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.
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.
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 :
Cette configuration est uniquement prise en charge via l’interface utilisateur.
Permet à un rôle de créer et de modifier des pipelines de traitement de logs, notamment en effectuant les actions suivantes :
Remarque : cette autorisation accorde également les autorisations Logs_Write_Processors (pour tous les processeurs sur tous les pipelines) en arrière-plan.
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,
logs_write_processors de votre région.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>"]
}
}'
Permet à un rôle de créer, de modifier ou de supprimer des archives de logs, notamment en effectuant les actions suivantes :
Cette autorisation est globale et permet à la fois de créer de nouvelles archives et de modifier ou de supprimer les archives existantes.
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 :
Guest.Customer Support.Customer Support, sauf s’ils ont également le rôle Audit & Security.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 :
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.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.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 :
CI-CD.CI-CD, car la vue historique qui en résulte est limitée aux membres ayant le rôle PROD ou ADMIN.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.
Accordez les autorisations suivantes pour gérer l’accès en lecture à des sous-ensembles de données de log :
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 :
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 :
Cette vue répertorie les éléments suivants :
Restricted Access : toutes les requêtes de restriction, ainsi que le ou les rôles associés.Unrestricted Access : tous les rôles qui disposent de l’autorisation log_read_data sans restriction supplémentaire.No Access : tous les rôles qui ne disposent pas de l’autorisation log_read_data.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é.
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é.
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.
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 :
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.
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.
audit et errors uniquement, il verra uniquement les logs service:api dans ces index.service:api dans le Live tail.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.
logs_write_processors de votre région.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>"]
}
}'
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.
Documentation, liens et articles supplémentaires utiles:
Sur cette page
