Athena, l'assistant

Le problème

Exploiter une plateforme signifie savoir quelle adresse parmi plusieurs centaines appeler, dans quel ordre, avec quel corps. La plupart de cette connaissance n’est pas intéressante : c’est le coût de poser une question simple comme « pourquoi ce déploiement redémarre-t-il ». Athena est la surface où la question est l’entrée.

Ce que c’est

Athena est deux services, et la séparation est toute la conception.

L’assistant détient la conversation. Il parle à un fournisseur de modèle, maintient la session et décide quelles opérations tenter. Il n’appelle jamais le plan de contrôle lui-même.

Le serveur d’outils est la seule chose qui le fait. Il publie un ensemble fixe d’opérations nommées — deployment_list, container_logs et sre_incidents en sont trois — chacune avec une forme d’entrée déclarée et une permission requise, et il transforme un appel en une requête contre l’API propre du plan de contrôle. Tout ce que l’assistant peut faire sur la plateforme, il le fait via l’une de ces opérations nommées, à l’intérieur d’un seul locataire, avec une vérification de permission devant.

La conséquence est que le jugement de l’assistant décide ce qu’il faut tenter, et rien d’autre. Il ne peut pas atteindre une adresse qu’aucun outil ne nomme, et il ne peut pas dépasser une permission que le principal du locataire détient.

Comment une requête voyage

Une personne tape dans la console. La console appelle les routes d’Athena du plan de contrôle. Le plan de contrôle supprime toute identité de locataire que l’appelant a fournie et injecte celle qu’il a lui-même vérifiée — une requête qu’il ne peut attribuer à exactement un locataire est refusée plutôt que servie généreusement, et le refus est enregistré. L’assistant émet ensuite une credential de courte durée portant ce même locataire, et le serveur d’outils émet la sienne pour appeler le plan de contrôle, avec une valeur dans la credential mise en correspondance avec un en-tête sur chaque écriture.

Aucun de ces sauts n’élargit la portée. Être opérateur de plateforme est un signal de privilège, pas une vue plus large : un opérateur agit toujours à l’intérieur d’un locataire nommé, et le code le dit à trois endroits différents parce que c’est l’hypothèse la plus susceptible d’être à nouveau cassée.

Les permissions ne proviennent que d’un seul côté

Chaque outil déclare la permission dont il a besoin. Les rôles qui détiennent cette permission ne sont pas écrits dans l’assistant — ils sont générés à partir de la concession propre au plan de contrôle.

Il s’agit d’une réparation, et non d’une préférence. Les deux étaient auparavant des copies maintenues à la main, et elles divergeaient : un développeur se voyait proposer l’outil qui déclenche un incident, puis se voyait refuser par le serveur en cours de conversation. Trois autres divergences de même nature ont été trouvées au même moment, dont deux noms de permissions que le plan de contrôle n’a jamais eus. Générer une moitié à partir de l’autre rend cette classe de défaut impossible à réintroduire discrètement — la référence des rôles est l’endroit où ce résultat généré réside désormais : chaque permission et les rôles qui la détiennent, lus depuis les propres accords du plan de contrôle.

La plupart des outils ne sont pas annoncés

De tout ce qui est enregistré — le nombre est dans la section suivante, et il est dérivé des enregistrements eux-mêmes plutôt que saisi ici — huit sont annoncés dans la liste par défaut du modèle : cinq lectures courantes et les trois assistants qui trouvent tout le reste. Un agent recherche une opération par intention, lit sa forme d’entrée et la demande par nom. Un outil atteint de cette manière est vérifié par rapport à la même permission qu’un appel direct — demander n’est pas exécuter.

Cela maintient la surface publiée petite sans rien masquer. Chaque opération enregistrée porte toujours une permission ; la liste complète de ces permissions et des rôles qui les détiennent se trouve dans la référence des rôles.

Ce que vous pouvez lui demander de faire

Athena atteint la plateforme via 198 opérations nommées, et chacune d’entre elles relève de l’un de ces domaines. Voici ce que vous pouvez lui demander :

• Trouver la bonne opération. Demander en termes simples quelque chose dont le nom exact n’est connu de personne. Seule une petite fenêtre de l’ensemble est exposée au modèle par défaut, et c’est ainsi que le reste est atteint.
• Ce qu’une spec peut contenir. L’autorité sur ce qu’un document de déploiement est autorisé à dire — les champs que le plan de contrôle accepte réellement et leurs formes, tirés du schéma généré par le plan de contrôle lui-même plutôt que d’une page tenue à jour par quelqu’un. Aussi les manifests qu’il détient actuellement, lus exactement tels qu’ils ont été téléchargés. Lecture seule. Rien ici ne télécharge un manifest ou ne modifie un schéma.
• Déploiements. Créer, lire, modifier, mettre à l’échelle, redémarrer et annuler un déploiement, et piloter une mise à jour progressive de type canary.
• Jobs et planifications. Travail qui s’exécute jusqu’à son terme : jobs ponctuels, leurs exécutions, et les planifications qui les créent.
• Conteneurs. Les conteneurs en cours d’exécution d’un déploiement : les lister, en inspecter un, lire sa sortie, et les opérations qui le modifient — redémarrer, arrêter, supprimer, et exécuter une commande à l’intérieur.
• Secrets. Métadonnées des secrets et rotation. Aucun outil ici ne renvoie de matériel secret, et aucun n’en accepte — une valeur saisie dans une conversation ne peut pas être effacée.
• Volumes et sauvegardes. Volumes persistants et les sauvegardes qui en sont faites.
• Réseaux. Réseaux de conteneurs et ce qui est attaché à chacun.
• Santé et diagnostics du cluster. La santé et les ressources de la flotte, et les lectures de diagnostic qu’un agent utilise quand quelque chose ne va pas.
• La piste d’audit. Ce qui s’est passé, qui l’a fait, et ce qui a été refusé.
• Incidents. Le répondeur automatique d’incidents, du côté de l’agent : lire les incidents, approuver une action proposée, et en déclencher un.
• Analyse de vulnérabilités. Ce qui est connu comme étant défectueux dans les images qu’un locataire exécute : analyser une image, lire ce qu’une analyse a trouvé, tester une image contre les règles, et la mise à jour qui corrige le problème. Les règles elles-mêmes — y compris les résultats à ignorer, et les seuils qui décident ce qui bloque un déploiement — peuvent être lues, réécrites et supprimées ici aussi, mais uniquement par un administrateur de la plateforme, et elles s’appliquent à tous les locataires plutôt qu’à un seul. L’enregistrement d’une exception de risque contre une règle n’est pas du tout ici : ni le fait d’en élever une ni le fait d’en approuver une n’a d’outil, et les deux sont des actes humains dans le tableau de bord.
• Volumes répliqués. Stockage conservé sur plus d’un nœud afin que la perte d’un n’entraîne pas la perte des données : où se trouvent les copies d’un volume, ses instantanés, le déplacer vers un autre nœud, et basculer vers une copie. Ce ne sont pas les mêmes objets que les volumes de conteneurs ci-dessus.
• Nœuds. Un nœud de la flotte : ce qu’il est, ses certificats et son état de routage de bord, s’il accepte du nouveau travail, déplacer le travail hors de celui-ci avant la maintenance, et ce qu’une mise à niveau de l’agent changerait. Admettre un nœud et approuver sa mise à niveau ne sont pas ici — les deux sont des actes humains enregistrés.
• Historique de configuration. L’historique conservé de la configuration d’un déploiement : quelles versions existent, quelle était la configuration à l’une d’entre elles, et rétablir une version antérieure.
• Mise à l’échelle automatique. Les règles qui décident quand un déploiement obtient plus ou moins de copies de lui-même, quelle est la règle de chaque déploiement actuellement, et ce que la plateforme a réellement fait à ce sujet — chaque décision de mise à l’échelle prise, et les totaux à travers celles-ci.
• Rapports de conformité. Preuves pour un audit : demander un rapport selon l’une des normes de conformité que cette plateforme sait comment répondre, voir quelles normes sont disponibles, lister ce qui a déjà été produit, et en lire un.
• Stacks. Un groupe de déploiements géré comme une seule chose : ce qu’il contient, et ce que le fait de le déplacer vers un modèle de gestion différent changerait.
• Tâches de migration. Travail de plateforme de longue durée qui déplace les stacks entre les modèles de gestion : ce qui est en cours, et où en est l’avancement.
• Lectures à l’échelle de la plateforme. Questions sur la plateforme plutôt que sur un seul déploiement : ce que le routeur de bord sert, si le certificat d’une adresse est valide et quand il expire, ce que coûte la plateforme, et où en est une migration d’environnement à l’échelle de la plateforme. Aussi les classes de priorité de planification que cette installation définit — quel travail est placé en premier lorsqu’un nœud ne peut pas tout contenir. Aussi les régions de résidence que ce plan de contrôle déclare, et si le placement géographique est appliqué par rapport à celles-ci.
• Récupération d’espace disque. Découvrir ce qu’un nettoyage à l’échelle de la plateforme d’images inutilisées, de conteneurs arrêtés et de réseaux morts supprimerait, et — en tant que requête distincte qui doit être confirmée — l’exécuter. Demander ce qui disparaîtrait n’est délibérément pas la même phrase que le faire disparaître. Administrateurs de la plateforme uniquement. Un nettoyage (prune) ne touche jamais aux volumes. La récupération d’espace ne peut pas coûter leurs données à un locataire.
• Pourquoi rien ne converge. La machinerie entre une instruction et un conteneur en cours d’exécution, pour le cas où l’instruction a été acceptée et que rien ne s’est produit : la passerelle qui transporte le travail vers chaque nœud et les disjoncteurs qui l’arrêtent lorsqu’un nœud tombe en panne, les réconciliateurs par locataire dont le travail est de faire correspondre la réalité à la spec, ce que cette installation exécute réellement, et si le registre de services propre à la plateforme est joignable. Administrateurs de la plateforme uniquement.

Ce qu’elle n’acceptera pas

Le matériel secret n’entre jamais dans une conversation. L’API propre du plan de contrôle accepte les valeurs secrètes en ligne ; les outils ne le font pas délibérément, et un appel qui en fournit un est refusé plutôt que silencieusement supprimé. Tout ce qui est saisi dans un chat se retrouve dans la transcription, le magasin de sessions et l’enregistrement d’audit des appels d’outils, dont aucun n’est le magasin de secrets et dont aucun ne peut être effacé par la suite. Ce que les outils acceptent à la place est une déclaration selon laquelle la plateforme doit générer le matériel, un chemin vers du matériel existant déjà, ou un modèle résolu à l’intérieur du plan de contrôle — voir secrets.

Rien ne traverse une frontière de locataire, et exécuter n’est pas construire : un assistant peut démarrer, modifier et arrêter des déploiements, et ne peut pas produire les images de conteneurs qu’ils exécutent.

Quel modèle, et la clé de qui

Trois fournisseurs sont pris en charge, et la clé peut appartenir à la plateforme ou au locataire : une clé par locataire est lue depuis le magasin de secrets sous le propre chemin de ce locataire, et la clé de la plateforme est la solution de repli. Un déploiement sans aucun magasin de secrets peut fournir des clés via l’environnement à la place, à la portée de la plateforme uniquement.

Not this

Cette page ne répertorie pas les outils ni leurs permissions — c’est la référence des rôles — et elle ne décrit pas la surface de configuration propre à l’assistant, qui relève de l’opérateur de la plateforme plutôt que de l’API d’un locataire.

Elle ne décrit pas non plus comment une conversation est stockée ni pendant combien de temps. C’est une question de conservation des données que cette page ne peut pas honnêtement répondre à partir du code seul.

Où le voir

• Chaque permission et les rôles qui la détiennent : référence des rôles.
• Ce qu’un principal agent ne peut pas faire, avant la planification : limites du principal agent.