Service DOCA Argus

Successeur actuellement promu. DOCA Argus est le framework principal et actuellement promu par NVIDIA pour la détection des menaces à l'exécution et l'analyse médico-légale de la mémoire hôte sur BlueField. Il remplace l'ancienne approche basée sur une bibliothèque DOCA App Shield (la bibliothèque DOCA App Shield n'est pas couverte par ce bundle — elle est exclue par politique de la version publique ; voir AGENTS.md ## Non-goals` point 7 et rediriger vers la documentation publique via doca-public-knowledge-map). Lorsqu'une demande porte sur « l'introspection des processus hôte / la détection d'activités suspectes / la sécurité à l'exécution » et demande le choix actuellement supporté, Argus est la réponse à nommer en premier ; la bibliothèque App Shield est le fallback de niveau inférieur uniquement pour l'outillage personnalisé côté DPU qu'Argus ne peut pas exprimer, et elle vit en dehors de ce bundle.

Par où commencer : Cette skill concerne l'exploitation du conteneur DOCA Argus Service, non la liaison contre une bibliothèque. Argus est l'agent de sécurité packagé qui se livre sous forme de conteneur et expose les résultats via son API / tableau de bord / SIEM transféré ; ce n'est pas un agent côté hôte que l'utilisateur installe en tant que paquet hôte, pas une surface de programmation, et pas la même chose que la bibliothèque DOCA App Shield (la bibliothèque d'introspection de niveau inférieur qu'un développeur utiliserait pour CONSTRUIRE un outillage de sécurité personnalisé — Argus est ce que la plupart des opérateurs veulent À LA PLACE ; la bibliothèque App Shield n'est pas couverte par ce bundle). Si l'utilisateur veut déployer le conteneur Argus, ouvrez TASKS.md et commencez par ## configure. Si la question porte sur quelle forme de service est Argus, ce qu'il détecte, et comment il expose les résultats, commencez par CAPABILITIES.md. Si DOCA n'est pas encore installé sur BlueField, rediriger d'abord vers doca-setup. Si la vraie question de l'utilisateur est « je veux écrire un outil de sécurité personnalisé contre l'état du kernel hôte depuis le côté BlueField », la bonne réponse n'est pas cette skill — c'est la bibliothèque DOCA App Shield, qui n'est pas couverte par ce bundle ; rediriger l'utilisateur vers la documentation publique via doca-public-knowledge-map à la place.

Exemples de questions auxquelles cette skill répond bien

Les CLASSES de questions Argus que cette skill est construite pour répondre, chacune avec un exemple travaillé. La classe est le point d'appui ; l'exemple travaillé est une instance.

« Pour un workflow de sécurité BlueField en production, dois-je déployer Argus ou construire mon propre outil sur la bibliothèque DOCA App Shield ? » — exemple travaillé : « je veux une sécurité à l'exécution sur une flotte de BlueField-3 protégeant un tier de base de données en production ; que dois-je privilégier ? ». Réponse fournie par la règle de sélection de chemin Argus-vs-App-Shield dans CAPABILITIES.md ## Safety policy
- l'étape de sélection de chemin dans TASKS.md ## configure.
« Quels quatre axes de configuration dois-je décider avant de démarrer le conteneur Argus ? » — exemple travaillé : « hôte de production surveillé par Argus, résultats transférés à Splunk, budget de faux positifs faible ». Réponse fournie par le tableau de configuration quatre-axes dans CAPABILITIES.md ## Capabilities and modes
- l'étape quatre-axes dans TASKS.md ## configure.
« Le conteneur Argus fonctionne mais je ne vois aucun résultat — qu'ai-je oublié ? » — exemple travaillé : « conteneur ok, aucun résultat n'est arrivé en 24h ». Réponse fournie par les lignes de politique de détection et d'échantillonnage dans CAPABILITIES.md ## Error taxonomy
- l'échelle en couches dans TASKS.md ## debug.
« Je reçois des centaines de résultats par heure et ils ressemblent à du bruit — Argus est-il cassé ? » — exemple travaillé : « trop de résultats ; les ops de sécurité commencent à ignorer le canal ». Réponse fournie par les règles de période d'étalonnage et de politique de détection dans CAPABILITIES.md ## Safety policy
- l'échelle en couches dans TASKS.md ## debug.
« Comment j'apparie Argus à mon SIEM existant (Splunk / ELK / …) ? » — exemple travaillé : « transférer les résultats à Splunk pour que l'équipe des ops de sécurité les examine ». Réponse fournie par la ligne d'axe de transfert dans CAPABILITIES.md ## Capabilities and modes
- l'étape de transfert dans TASKS.md ## configure.
« Mon déploiement Argus impacte les performances de la charge — que dois-je régler ? » — exemple travaillé : « le CPU de l'hôte de production a augmenté notablement depuis le démarrage d'Argus ». Réponse fournie par la ligne d'axe d'échantillonnage dans CAPABILITIES.md ## Capabilities and modes
- la ligne d'ajustement d'échantillonnage dans TASKS.md ## debug.

Audience

Cette skill sert les opérateurs de sécurité externes et les équipes de plateforme qui déploient le conteneur DOCA Argus Service pour obtenir une sécurité à l'exécution sur une paire BlueField + hôte, avec des résultats s'écoulant vers le SIEM existant de l'équipe. Concrètement : des personnes exécutant le conteneur Argus sur BlueField Arm, choisissant sa politique de détection / destination de transfert / échantillonnage / couverture hôte d'après le guide Argus public, câblant l'ingestion côté SIEM pour que les résultats atteignent l'équipe des ops de sécurité, et validant le pipeline de bout en bout avant de faire confiance au canal pour des décisions de qualité production.

Ce n'est pas pour les développeurs NVIDIA contribuant à Argus lui-même, et ce n'est pas un guide de programmation pour construire des outils de sécurité sur les bibliothèques DOCA (c'est doca-programming-guide plus la skill correspondante libs/<library> — et pour la bibliothèque App Shield sur laquelle construire un outillage de sécurité personnalisé, la documentation publique, puisque App Shield n'est pas couverte par ce bundle). Argus est un service, pas une bibliothèque : l'opérateur lance un conteneur et consomme les résultats via l'API documentée / tableau de bord / forwarder SIEM ; il ne lie pas contre un libargus.so pour écrire son propre programme.

Sélection de chemin en amont (point d'appui). Utiliser Argus quand l'utilisateur veut une sécurité à l'exécution en production sur BlueField comme un workflow packagé — la plupart des opérateurs dans cette position devraient privilégier Argus plutôt que de construire leur propre outil sur la bibliothèque DOCA App Shield. Argus est le produit packagé ; App Shield est la bibliothèque qu'un développeur n'utiliserait que si Argus est vraiment insuffisant (par exemple, l'équipe construit un produit de sécurité propre qui doit embarquer sa propre logique de décision). Ne pas utiliser Argus quand (a) il n'y a aucune préoccupation de posture de sécurité (Argus est une surcharge importante pour rien) ; (b) l'utilisateur veut vraiment l'observabilité / les métriques plutôt que la sécurité (rediriger vers DOCA Telemetry Service via doca-public-knowledge-map ## DOCA services) ; (c) l'utilisateur construit son propre outillage de sécurité personnalisé côté DPU (c'est la bibliothèque DOCA App Shield — l'équivalent de bibliothèque, même forme d'observation côté BlueField, forme différente d'effort d'opérateur — qui n'est pas couverte par ce bundle ; rediriger vers la documentation publique via doca-public-knowledge-map).

Quand charger cette skill

Charger cette skill quand l'utilisateur effectue un travail de déploiement Argus direct sur un BlueField où DOCA est déjà installé. Concrètement :

Décider si Argus est la bonne réponse pour la posture de sécurité de l'utilisateur (vs. construire un outillage personnalisé sur la bibliothèque DOCA App Shield — non couverte par ce bundle, vs. déployer l'observabilité à la place de la sécurité, vs. ne rien déployer si aucune préoccupation de posture).
Déployer le conteneur Argus sur BlueField Arm — choisir la source d'image d'après le guide public DOCA Argus Service, monter la config Argus, et démarrer / arrêter le conteneur d'après le pattern du guide public Container Deployment.
Choisir les quatre axes de configuration — politique de détection (quelles classes d'anomalies alerter), destination de transfert (logs locaux / SIEM comme Splunk / ELK / Sentinel), échantillonnage / sensibilité (compromis faux positifs vs faux négatifs), couverture hôte (quelles cibles hôte le déploiement Argus surveille) — pour le déploiement de l'utilisateur.
Câbler l'ingestion côté SIEM pour que les résultats émis par le conteneur Argus atteignent réellement la surface de révision de l'équipe des ops de sécurité — sans cette étape Argus génère les résultats dans le vide.
Valider le pipeline de bout en bout (conteneur Argus → émission de résultats → forwarder → ingestion SIEM → révision ops) et parcourir la période d'étalonnage avant de faire confiance au canal pour des décisions en production.
Lire les logs du conteneur Argus, le feed de résultats documenté, ou toute autre surface d'observabilité documentée pour confirmer que le déploiement fonctionne comme configuré.
Déboguer un déploiement Argus où le conteneur est sain mais aucun résultat n'arrive, ou trop de résultats arrivent pour être utiles, ou des résultats sont générés mais n'atteignent pas le SIEM, ou Argus impacte les performances de la charge.

Ne pas charger cette skill pour l'orientation générale DOCA, l'installation de DOCA lui-même, les questions d'API de bibliothèque, ou les sujets non-sécurité. Pour ceux-ci, rediriger via doca-public-knowledge-map, doca-setup, ou la skill correspondante libs/<library> (et vers la documentation publique pour la bibliothèque DOCA App Shield quand l'utilisateur construit son propre outillage de sécurité côté DPU, puisque App Shield n'est pas couverte par ce bundle).

Ce que cette skill fournit

C'est un thin loader. Le matériel substantiel vit dans deux fichiers compagnons :

CAPABILITIES.md — l'architecture d'Argus (conteneur de longue durée qui possède la surface d'observation de sécurité à l'exécution sur BlueField), les quatre axes de configuration (politique de détection / transfert / échantillonnage / couverture hôte), la forme de déploiement (conteneur sur BlueField Arm d'après le guide public Container Deployment), la surface d'appairage (consommateurs SIEM — Splunk, ELK, Sentinel, …), la surface d'observabilité (logs du conteneur + feed de résultats + confirmation d'ingestion côté SIEM), la taxonomie des erreurs (container-runtime / detection-policy / forwarding / sampling-performance / host-coverage), et la politique de sécurité (sélection de chemin Argus-vs-App-Shield, jamais désactiver silencieusement les résultats, s'attendre à une période d'étalonnage, smoke-before-bulk).
TASKS.md — workflows étape par étape pour les verbes Argus de périmètre : configure, build, modify, run, test, debug, plus un bloc Deferred task verbs redirigeant les questions hors périmètre et une Command appendix de commandes récurrentes.

La skill suppose un BlueField où DOCA est déjà installé et l'opérateur a les privilèges que le guide public Argus Service Guide s'attend à tirer, exécuter et configurer les conteneurs sur BlueField Arm. Elle ne couvre pas l'installation de DOCA — ce chemin passe par doca-setup. Elle ne couvre pas la configuration d'ingestion côté SIEM en détail — le SIEM est l'infrastructure existante de l'utilisateur, propriété de la propre documentation du SIEM ; le travail d'Argus est d'émettre les résultats au format forwarder documenté, et le travail de l'équipe SIEM de l'utilisateur est de les recevoir.

Ce que cette skill ne livre délibérément pas

Cette skill est une guidance d'agent, pas un bundle de templates ou de configs exemples. Pour garder la limite nette, elle ne contient délibérément pas — et les pull requests ne devraient pas ajouter :

Fichiers de configuration Argus pré-cuits (blocs de politique de détection complets, configs de forwarder prêtes à l'emploi, templates d'échantillonnage) destinés à être copy-pastés en production. La politique de détection est profondément spécifique à la charge (un tier de base de données et un tier web ont des comportements de base différents qui se traduisent en anomalies dignes d'alertes différentes), et une politique copy-pastée garantit presque certainement ou une inondation de faux positifs ou des points aveugles silencieux. La réponse sûre pour un opérateur externe est de dériver la config d'après le guide public Argus Service contre sa propre charge, puis parcourir la période d'étalonnage. Le travail de l'agent est de prescrire la procédure et la décision quatre-axes, pas de livrer une config que l'utilisateur pourrait exécuter sans modification.
Noms d'image de conteneur, tags, ou chemins de registry. La source d'image faisant autorité est le guide public DOCA Argus Service accessible via doca-public-knowledge-map ## DOCA services ; le tag d'image d'Argus est lié à la version et change entre les versions DOCA. Inventer ou mémoriser un tag est le mode de défaillance hallucination canonique pour une skill de service.
Configurations d'ingestion côté SIEM (stanzas de forwarder Splunk, définitions de pipeline Logstash, blocs de data-connector Sentinel). Ceux-ci sont spécifiques à l'environnement SIEM et vivent côté SIEM, pas à l'intérieur du conteneur Argus. La skill nomme que la destination de transfert doit être câblée et quel est le format forwarder documenté ; le corps de l'ingestion côté SIEM appartient à l'équipe SIEM de l'utilisateur et à la documentation de ce SIEM.
Packs de règles de détection d'aucune sorte (listes de « motifs à alerter obligatoires », tables de thresholding, mappages nommés CVE). La politique de détection est la surface du guide public Argus Service et la décision spécifique à la charge de l'utilisateur ; un pack de règles livré dans cette skill contourne à la fois le guide et le travail d'étalonnage de l'opérateur et devient une guidance d'agent obsolète le jour où une nouvelle version change la surface.
Un sous-arbre samples/, templates/, ou reference/ d'aucune sorte. Un artefact fictif ou incomplet dans l'arbre de cette skill, même étiqueté « reference », est trompeur : les opérateurs le liront comme prêt pour la production et validé en sécurité, dont cette skill ne peut garantir ni l'un ni l'autre.

Ordre de chargement

Lire d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est en périmètre et qu'Argus est la bonne réponse tout court (vs. construire sur la bibliothèque DOCA App Shield — non couverte par ce bundle, vs. ne rien déployer, vs. déployer l'observabilité à la place).
Pour la forme de déploiement d'Argus, les quatre axes de configuration, la surface d'appairage SIEM, la taxonomie des erreurs, la surface d'observabilité, et la politique de sécurité (incluant la règle de période d'étalonnage et la règle de ne jamais désactiver silencieusement), voir CAPABILITIES.md.
Pour les workflows étape par étape — configure, build, modify, run, test, debug — voir TASKS.md.

Skills liées

doca-public-knowledge-map — la table de routage vers le guide public DOCA Argus Service et le reste de l'ensemble de la documentation DOCA publique. L'URL Argus est listée sous ## DOCA services.
doca-setup — préparation d'env et vérification d'installation sur le BlueField où le conteneur Argus s'exécutera, incluant le chemin je n'ai pas encore d'installation via le conteneur NGC DOCA public. Cette skill suppose que ses préconditions sont satisfaites sur BlueField Arm.
doca-version — règles de traitement de version DOCA canoniques. Le tag de conteneur d'Argus est lié à la version ; la ## Version compatibility de cette skill cross-linke la règle de correspondance quatre-voies et ajoute l'overlay container-tag-lags-host-package partagé avec chaque autre conteneur de service DOCA.
doca-structured-tools-contract — la règle de préséance structured-tools du bundle (detect / prefer / fall back / report). La Command appendix dans TASKS.md honore ce contrat.
doca-programming-guide — patterns DOCA généraux. Argus a une forme service et non library, donc le pattern build / modify / first-app là ne s'applique pas directement, mais la discipline de débogage cross-library (frontend-before-backend, env-before-program, never-invent-flags) reste utile quand Argus rapporte une erreur qui a originé dans le runtime du conteneur ou dans une bibliothèque DOCA qu'il a appelée.
Bibliothèque DOCA App Shield — l'équivalent de bibliothèque, la bibliothèque d'introspection de niveau inférieur sur laquelle un développeur construit un outillage de sécurité personnalisé côté DPU. Elle n'est pas couverte par ce bundle (exclue par politique de la version publique) ; quand Argus est vraiment insuffisant et l'équipe doit construire son propre produit de sécurité, rediriger vers la documentation publique via doca-public-knowledge-map. La règle de sélection de chemin dans CAPABILITIES.md ## Safety policy redirige l'utilisateur vers Argus en premier pour la sécurité en production.
doca-dms et doca-firefly — skills de service sibling. L'agent lisant deux de celles-ci devrait voir la même forme de service-skill (conteneur, BlueField Arm, Container Deployment Guide comme la recette canonique, smoke-before-bulk, préconditions d'env, schéma de config, l'ancre de version est le tag du conteneur) superposée sur un domaine per-service différent (DMS = gestion d'appareil via gNMI / gNOI ; Firefly = synchronisation du temps via PTP ; Argus = sécurité à l'exécution via émission de résultats).
doca-debug — l'échelle de débogage cross-cutting (install / version / build / link / runtime / program / driver). Le débogage spécifique à Argus (aucun résultat qui arrive, trop de résultats, résultats non transférés, impact de performance) se superpose sur le haut de cette échelle.

doca-argus