Configuration de la table de référence BYOD Preferences

Aidez les clients à créer et télécharger une table de référence k9_ownership_preferences pour personnaliser la façon dont l'Ownership Agent détermine les propriétaires de ressources.

À lire en priorité

• references/schema.md — schéma complet, détails des colonnes, règles de validation et exemples par type
• assets/example.csv — CSV complet et fonctionnel avec les trois types de préférences

Vue d'ensemble

L'Ownership Agent déduit les propriétaires des ressources cloud ayant des constats de sécurité. Les préférences de propriété permettent aux clients de personnaliser cela en fournissant des règles dans une table de référence Datadog. L'agent les lit automatiquement.

Avec les préférences, vous pouvez :

• Mapper les tags aux propriétaires : Les ressources avec des valeurs de tag spécifiques appartiennent à une équipe ou personne particulière
• Exclure des comptes : Empêcher les comptes bot ou l'infrastructure partagée d'apparaître comme propriétaires
• Fournir des conseils personnalisés : Donner au moteur IA un contexte spécifique à votre organisation

Détails de la table de référence

• Nom de la table : k9_ownership_preferences (nom exact, doit correspondre)
• Délai d'effet : Les modifications prennent effet dans les 24 heures suivant le téléchargement
• Schéma : 12 colonnes, toutes STRING — voir references/schema.md pour les détails

Workflow

Étape 1 : Déterminer les besoins

Posez au client les questions suivantes :

• Mappages de tags : « Avez-vous des tags sur vos ressources cloud qui indiquent la propriété ? (par exemple, cost-center, team, project) »
• Exclusions : « Y a-t-il des comptes bot, des comptes de service ou des comptes partagés qui ne devraient jamais apparaître comme propriétaires ? »
• Texte de prompt : « Existe-t-il un contexte spécifique à votre organisation qui aiderait à déterminer la propriété ? (par exemple, conventions de nommage, structure d'équipe) »

Étape 2 : Générer le CSV

Consultez references/schema.md pour la spécification complète des colonnes et assets/example.csv pour un modèle fonctionnel. Construisez un CSV avec les 12 en-têtes de colonne. Chaque ligne reçoit un id séquentiel unique et remplit les colonnes pertinentes selon son preference_type, en laissant le reste vide.

Étape 3 : Instructions de téléchargement

Option A — Téléchargement CSV (interface utilisateur) :

1. Allez dans Integrations > Reference Tables dans Datadog
2. Cliquez sur New Reference Table
3. Téléchargez le CSV
4. Définissez le nom de la table sur k9_ownership_preferences
5. Choisissez la clé primaire : preference_type, tag_key, tag_value, handle
6. Enregistrez

Les téléchargements manuels supportent les fichiers jusqu'à 4 MB.

Option B — Synchronisation du stockage cloud (S3, Azure Blob, GCS) : Idéale pour les mises à jour automatisées et récurrentes. Stockez votre CSV dans un bucket de stockage cloud et Datadog l'importe périodiquement.

1. Téléchargez le CSV sur S3 / Azure Blob / GCS
2. Dans Datadog, allez à Integrations > Reference Tables
3. Cliquez sur New Reference Table, sélectionnez Cloud Storage comme source
4. Fournissez le chemin de stockage et les identifiants
5. Définissez le nom de la table sur k9_ownership_preferences
6. Datadog réimporte le fichier périodiquement

Les téléchargements du stockage cloud supportent les fichiers jusqu'à 200 MB.

Option C — Terraform : Utilisez la ressource datadog_reference_table dans le fournisseur Datadog Terraform pour gérer la table en tant que code d'infrastructure.

Option D — API : Vous pouvez gérer les tables de référence par programme via l'API Reference Tables. Consultez la documentation de l'API pour connaître les endpoints disponibles. Remplacez le domaine API par l'URL de votre site Datadog le cas échéant.

Étape 4 : Vérifier

Les modifications prennent effet dans les 24 heures. Pour vérifier :

1. Identifiez une ressource qui correspond à l'un de vos mappages de tags
2. Après 24 heures, vérifiez la suggestion de propriétaire pour cette ressource dans l'interface utilisateur Datadog
3. Le propriétaire suggéré doit refléter votre mappage configuré

Comportements clés

• Correspondance insensible à la casse : Les clés de tag, les valeurs de tag, les handles, les types d'exclusion et les types de ressources sont tous appariés de manière insensible à la casse
• Exclusions avec logique ET : Tous les champs d'exclusion non vides doivent correspondre. Les champs vides agissent comme des caractères génériques
• Les mappages de tags complètent, ne remplacent pas : Les indicateurs de propriété directe (comme les tags team: ou service:) ont la priorité. Les mappages de tags augmentent, ne remplacent pas
• Dégradation gracieuse : Si la table n'existe pas ou est vide, la détection de propriété fonctionne normalement sans préférences
• La table vide efface les préférences : Supprimer toutes les lignes ou supprimer la table provoque l'expiration des préférences en cache et les laisse vides
• Validation du tout ou rien : Toute défaillance de validation rejette l'ensemble complet des préférences pour ce cycle

Dépannage