Présentation

Les politiques d’exécution vous permettent de contrôler qui, où et quelles actions votre équipe peut exécuter. Chaque politique d’exécution est une règle unique d’autorisation ou de refus pour un ensemble d’actions, ainsi que pour les Datadog Agents auxquels elle s’applique. Vous sélectionnez ces Datadog Agents à l’aide de tags d’Agent. Les politiques d’exécution vous offrent deux avantages principaux lorsque vous autorisez des actions privées :

• Gérer l’accès à grande échelle : Avec Connections, vous créez une connexion par intégration sur chaque runner, ce qui devient difficile à gérer sur une large flotte. Les politiques d’exécution vous permettent de contrôler l’accès à de nombreux runners à la fois en sélectionnant des Datadog Agents à l’aide de tags. Une seule politique peut également lister plus d’un ensemble de Datadog Agents cibles, de sorte que la même règle peut couvrir plusieurs équipes ou environnements sans être dupliquée.
• Contrôle précis : Vous pouvez autoriser ou refuser des actions spécifiques ou des ensembles d’actions, et appliquer des scopes spécifiques à l’intégration, par exemple en limitant une politique Kubernetes à des espaces de noms cibles spécifiques.

Les politiques d’exécution s’appliquent aux private action runners fonctionnant au sein du Datadog Agent qui ont été inscrits comme sans propriétaire. Un private action runner sans propriétaire est inscrit avec une clé d’API qui possède la capacité Private Action Runner, plutôt qu’être associé à un utilisateur spécifique. Pour savoir comment un private action runner devient sans propriétaire, consultez Inscription et propriété.

Prérequis

• Un private action runner fonctionnant au sein du Datadog Agent et inscrit comme étant sans propriétaire (à l’aide d’une clé d’API possédant la capacité Private Action Runner).
• La permission ExecutionGroupWrite, qui vous permet de créer, mettre à jour et supprimer des politiques d’exécution. Voir Permissions.

Autorisations

La création, la mise à jour et la suppression de politiques d’exécution nécessitent la permission ExecutionGroupWrite.

• Le rôle par défaut Datadog Admin inclut cette permission.
• Pour l’accorder à d’autres utilisateurs, ajoutez-la à un rôle personnalisé et attribuez ce rôle aux utilisateurs ou aux équipes qui gèrent les politiques d’exécution.

Cette permission contrôle qui peut gérer les politiques d’exécution. Pour contrôler qui peut utiliser une politique d’exécution spécifique pour exécuter des actions privées, consultez les paramètres Access de cette politique d’exécution.

Structure de la politique

Une politique d’exécution est une règle unique d’autorisation ou de refus pour un ensemble d’actions privées. Elle est composée de composants, notamment les actions qu’elle couvre et des Agents cibles auxquels elle s’applique.

Les sections Targets et Access décrivent ces composants en détail. Pour créer une politique d’exécution avec tous ses composants, consultez la section Créer une politique d’exécution.

Créer une politique d’exécution

1. Allez dans Actions > Execution Policies et cliquez sur Create Execution Policy.
2. Saisissez un nom dans Name (par exemple, Read-only Kubernetes) ou utilisez celui qui est automatiquement généré.
3. Définissez Effect sur Allow ou Deny.
4. Sous Actions, choisissez une intégration et les actions à inclure. Vous pouvez sélectionner des actions spécifiques, sélectionner des ensembles entiers ou utiliser les sélecteurs spéciaux Toutes les actions / Toutes en lecture seule.
5. Définissez éventuellement un périmètre. Par exemple, pour Kubernetes, définissez Target Namespaces pour limiter la politique à des espaces de noms spécifiques.
6. Sous Targets, ajoutez une ou plusieurs tags pour sélectionner les Datadog Agents auxquels s’applique cette politique. Un Datadog Agent doit porter tous les tags d’une Target pour y correspondre. Pour cibler chaque Datadog Agent sur lequel un private action runner sans propriétaire est activé, utilisez un caractère générique * seul. Ajoutez plusieurs Targets pour appliquer la même politique à plusieurs ensembles de Datadog Agents. Pour plus d’informations, consultez la section Targets.
7. Under Access, définissez qui peut visualiser, modifier et à qui la politique s’applique. Pour plus d’informations, consultez la section Access.
8. Click on Create.

Utiliser une politique d’exécution dans un workflow

Lorsque vous configurez une étape private action dans un workflow, vous pouvez cibler un Datadog Agent directement au lieu de sélectionner une connexion :

1. Dans le sélecteur de connexion de l’étape, choisissez Target au lieu de Connection.
2. Sélectionnez comment identifier le Datadog Agent:
   • Hostname : pour un private action runner sur un host Datadog Agent spécifique.
   • Orch Cluster ID : pour un private action runner dans un Kubernetes Cluster Agent.
3. Saisissez le hostname ou l’Orch Cluster ID du target Datadog Agent.

Cela crée une connexion virtuelle pour l’étape, identifiée uniquement par le target Datadog Agent ; elle ne contient aucune information d’identification. Lorsque le workflow s’exécute, l’action s’exécute uniquement si une politique d’exécution l’autorise pour ce Target et pour l’utilisateur demandeur.

Intégrations prises en charge

Les politiques d’exécution autorisent des actions pour les intégrations suivantes :

• Kubernetes (com.datadoghq.kubernetes.*)
• Remote Action (com.datadoghq.remoteaction.*), qui inclut le bundle rshell (action runCommand) et les actions Network Path.
• Script (com.datadoghq.script.*).

La Private Action Runner Reference indique les actions prises en charge par chaque type de runner. Si votre intégration ne peut pas être autorisée via des politiques d’exécution, utilisez plutôt Connections.

Politiques d’exécution par défaut

Datadog provisionne les politiques d’exécution par défaut dans votre organisation afin que les actions en lecture seule fonctionnent dès qu’un runner s’inscrit. Aucune configuration de votre part n’est requise. Elles :

• Ciblent chaque Agent qui exécute un private action runner (sélecteur de cible *).
• Accordent des actions Kubernetes en lecture seule et Remote Action en lecture seule.
• Permettez à tout le monde de votre organisation d’exécuter ces actions en lecture seule. Les utilisateurs disposant de l’autorisation ExecutionGroupWrite, incluse par défaut dans le rôle Datadog Admin, peuvent également les modifier.

Les politiques d’exécution par défaut ne couvrent que les actions en lecture seule. Pour exécuter des actions en écriture, ou pour limiter l’accès à des Agents, espaces de noms, équipes ou utilisateurs spécifiques, consultez Créer une politique d’exécution.

Workflow d’autorisation

Comme l’autorisation s’effectue dans Datadog avant l’envoi d’une tâche, le runner n’exécute que les actions qui ont déjà été autorisées. Lorsqu’une action privée est demandée sur un runner dans le Datadog Agent :

1. Datadog identifie le target Agent (par nom de host ou orchestration cluster ID) et ses tags.
2. Datadog trouve les politiques d’exécution dont les Targets correspondent à ces tags.
3. Datadog évalue les politiques correspondantes pour l’action demandée et l’utilisateur demandeur.
4. Si une politique autorise l’action et qu’aucune politique ne l’interdit, la tâche est envoyée à l’Agent, qui l’exécute. Sinon, l’action est refusée et n’atteint jamais l’Agent.

L’évaluation suit deux règles :

• Default deny : si aucune politique n’autorise explicitement l’action, celle-ci est refusée.
• Deny overrides allow : si une politique correspondante refuse l’action, celle-ci est refusée, même si une autre politique l’autorise.

Les politiques d’exécution ne stockent pas d’identifiants. Elles répondent à la question de savoir où les actions peuvent s’exécuter, quelles actions peuvent s’exécuter et qui peut les exécuter.

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles:

Présentation des Private ActionsDOCUMENTATION Inscription et propriétéDOCUMENTATION Autoriser les actions privéesDOCUMENTATION ConnexionsDOCUMENTATION