Règles d’entrée client et migration

Ces règles sont introduites dans Auton 1.4.0, version de transition. Les valeurs par défaut changent avec Auton 2.0, disponible pour des tests isolés en version 2.0.0rc3.

Dans la version de transition, les réglages allow-* absents conservent les permissions 1.x et produisent des avertissements au démarrage pour chaque opération et catégorie concernée. Ces avertissements ne bloquent pas le démarrage et ne contiennent jamais les valeurs des arguments ou des variables. La commande en lecture seule autond --check-migration -c config.yml signale aussi les règles manquantes. En 2.0, une permission absente interdit les ajouts du client. Un refus renvoie explicitement HTTP 400 avant admission ; le démon continue de traiter les autres requêtes. Une syntaxe de règle invalide constitue une erreur de configuration au démarrage.

Arguments et environnement

endpoints:
  report:
    plugin: subproc
    config:
      prog: /opt/scripts/report.sh
      args: ["--format", "pdf"]
      allow-args:
        month:
          regex: '20[0-9]{2}-(0[1-9]|1[0-2])'
          repeatable: true
          nargs: '+'
        verbose:
          nargs: 0
      allow-env:
        TZ:
          choices: [UTC, Europe/Paris]
      disallow-env: [LD_PRELOAD, PYTHONPATH]

allow-args: [month] accepte --month VALUE ou --month=VALUE, avec une valeur de contenu quelconque et une seule occurrence. Un nom nu désigne une option longue ; utilisez -m pour autoriser précisément cette option courte. month: 'REGEX' est une forme abrégée de règle d’expression régulière. Une règle peut contenir regex, choices, repeatable et nargs. Les expressions régulières doivent correspondre à la valeur entière, avec un temps d’évaluation limité. Les choix doivent être des chaînes YAML ; mettez entre guillemets les valeurs d’apparence numérique. Les deux contraintes s’appliquent si elles sont configurées ensemble. Les noms de variables sont littéraux et sensibles à la casse ; nargs et repeatable concernent uniquement les arguments.

nargs accepte 0 (un indicateur sans valeur), un entier fixe, + (une ou plusieurs valeurs) ou * (zéro ou plusieurs). Chaque valeur est vérifiée séparément. Les répétitions sont refusées sauf avec repeatable: true. Une règle restrictive refuse les options inconnues, les arguments positionnels, les abréviations et les formes courtes compactes comme -abc ou -mVALUE. Les valeurs commençant par un tiret ressemblant à une option doivent utiliser --month=VALUE ; les nombres négatifs comme -1 peuvent aussi être séparés. Auton conserve les arguments d’origine, leurs répétitions et leur ordre. Il ne construit pas de commande shell, ne transforme pas les valeurs et ne décide pas comment le programme cible interprète les options répétées.

Ouvrir une catégorie et définir des exceptions

allow-args: true
allow-env: true
allow-argfiles: true
allow-envfiles: true
disallow-args: [dangerous-option, '-x']
disallow-env: [LD_PRELOAD]
disallow-envfiles: [/etc/auton/private.env]

Cet exemple autorise explicitement les quatre catégories, sauf les refus nommés. disallow-*: true interdit toute la catégorie, même si elle est autorisée. false n’ajoute aucun refus ; en 2.0, il n’accorde pas de permission à lui seul. Une liste d’autorisations vide n’accorde rien. Une liste de refus correspond aux noms exacts, sans connaître les alias du programme ; listez chaque alias ou préférez une liste d’autorisations. Les options courtes compactes sont refusées lorsque les arguments sont libres avec des exceptions. Le marqueur littéral -- termine l’analyse des options uniquement si les arguments sont libres. Le programme appelé reste responsable de sa propre interprétation. Réservez l’accès illimité explicite aux appelants de confiance.

Fichiers

Les fichiers et valeurs déclarés dans les réglages args, env, argfiles ou envfiles du serveur restent utilisables indépendamment des permissions du client.

Les argfiles du client sont des fichiers téléversés, pas des chemins sélectionnés sur le serveur. Auton décode les octets téléversés dans un répertoire temporaire privé et transmet le chemin du fichier au programme. allow-argfiles: ['-f'] autorise cette option de téléversement ; une règle peut valider le nom de fichier d’origine et autoriser les répétitions. La syntaxe -f@ est contrôlée comme -f et transmet toujours une valeur @path aux programmes qui la prennent en charge. Cette permission est distincte de allow-args ; aucune n’accorde l’autre. Le contenu reste une donnée opaque du programme : JSON, certificats, fichiers binaires, etc. Il n’est pas analysé comme des arguments CLI. N’autorisez pas une option de fichier dont le comportement dans le programme cible donnerait davantage de pouvoir que prévu à l’appelant.

Les envfiles du client sélectionnent des fichiers existants sur le serveur. Définissez allow-envfiles à true ou à une liste de chemins absolus exacts. Les exceptions utilisent disallow-envfiles. Les chemins résolus sont contrôlés : un lien symbolique ne permet donc pas de contourner un chemin résolu interdit. Les administrateurs doivent contrôler les fichiers autorisés et leurs répertoires parents. L’ancien nom de préversion allow-client-envfiles reste un alias avec avertissement ; ne configurez qu’un seul des deux noms.

allow-envfiles: [/etc/auton/report.env]
allow-env:
  TZ:
    choices: [UTC, Europe/Paris]

Chaque variable lue dans un fichier sélectionné par le client doit aussi respecter allow-env / disallow-env, y compris si une autre source la remplace ensuite. Auton lit chaque fichier une seule fois avant la mise en file, le valide et utilise cet instantané pour l’exécution ; une modification ultérieure du fichier ne change pas les tâches admises. Seuls les fichiers ordinaires UTF-8 de 1 Mio maximum sont lus. Une valeur vide s’écrit NAME= ; une clé sans = n’a pas de valeur chaîne et est refusée. Avec des règles explicites, ${...} reste littéral : l’environnement du démon n’est jamais développé. La transition conserve l’interpolation dotenv historique uniquement lorsque les règles envfile et environnement sont entièrement implicites. Placez les fichiers fixes dans la configuration serveur ou déclarez leurs chemins et les règles de leurs variables.

Étapes de migration

  1. Examinez les avertissements au démarrage ou le rapport de migration hors ligne.

  2. Ajoutez des règles sélectives pour chaque entrée client utilisée par l’opération, ou définissez explicitement ses réglages allow-* à true pour conserver un accès illimité.

  3. Testez les appels valides et invalides sur la version de transition.

  4. Testez une copie de la configuration en 2.0 avant de mettre à jour la production.

Les quatre permissions doivent être explicites pour conserver les entrées client illimitées de la 1.x. Les booléens disallow-* existants restent pris en charge. Une entrée invalide est refusée intégralement ; Auton ne supprime jamais silencieusement une option ou une variable interdite. Les erreurs indiquent l’option ou la catégorie sans révéler sa valeur. Une règle valide des chaînes de 64 Kio maximum, sans octet NUL ; les limites habituelles de taille et de nombre d’entrées restent applicables.

Réutiliser les blocs de règles

Auton 1.5.0 et 2.0.0rc3 prennent en charge six imports de blocs YAML terminaux, y compris depuis import_config. Les règles importées utilisent la même syntaxe.