Scénario #22026
Mis à jour par William Petit il y a plus de 8 ans
h2. Fonctionnalité
L’application Zéphir devrait avoir un lien logique entre les instances de Server et les machines (“minions”) appairées avec le processus salt-master.
La cinématique classique décrite dans la documentation (https://docs.saltstack.com/en/latest/topics/tutorials/walkthrough.html#using-salt-key) indique que le minion effectue une demande d’appairage sur le master et que celui ci accepte (ou non) la demande via la commande salt-key.
Cette cinématique est elle compatible avec le mode de fonctionnement attendu de Zéphir ? L’initiative de l’appairage ne devrait il pas venir du Zéphir ?
h2. Proposition
Statuer sur la procédure d’appairage via Salt d’une machine avec Zéphir puis implémenter la solution retenue.
h3. Possibilité 1 (appairage "classique" SaltStack à l'initiative du minion) Procédure proposée (en accord avec la stratégie classique d’appairage SaltStack)
# L'utilisateur L’utilisateur configure sur sa nouvelle machine son "minion" “minion” SaltStack et le fait pointer vers la machine Zéphir (ou le salt-master utilisé par Zéphir)
# Le "minion" “minion” envoie sa clé publique au salt-master et attend son approbation
# Sur le Zéphir, l'utilisateur l’utilisateur créait un nouveau :ref:`server` Server sur Zéphir (avec le bon :ref:`server-model` ServerModel associé)
# L'utilisateur "appaire" L’utilisateur “appaire” manuellement son instance :ref:`server` Server avec une des clés publiques de "minion" “minion” en attente d'approbation d’approbation
# La machine "minion" “minion” est désormais pilotable via le Zéphir
Ce mode de fonctionnement pose la question de l'affichage des demandes d'approbation. Quid du filtrage en fonction des droits d'accès ?
L'étape 4 devrait concentrer la majeure partie du travail de réflexion/développement.-
h3. Possibilité 2 (appairage à l'initiative du master)
# Sur le Zéphir, l'utilisateur créait un nouveau :ref:`server` sur Zéphir (avec le bon :ref:`server-model` associé)
# Le service `saltmaster` réagit à la création de ce nouveau :ref:`server` et créait un paire de clés cryptographiques à destination du minion. La paire de clé est dédiée/liée au :ref:`server`.
# L'utilisateur récupère cette paire de clés via l'interface et la déploie manuellement sur la machine avec le minion
Cette procédure découle du mode de déploiement `preseed` proposé dans la documentation SaltStack. Voir https://docs.saltstack.com/en/latest/topics/tutorials/preseed_key.html.
L’étape 4 devrait concentrer la majeure partie du travail de réflexion/développement.
D’autres méthodologies sont possibles, notamment via un génération d’une paire de clés “pré-approuvées” directement sur le Zéphir et un déploiement manuel sur la machine “minion”.
h2. Critères d'acceptation
* On peut faire le lien entre un “minion” appairé sur le salt-master et un Server sur l’application Zéphir
h2. Documentation
https://dev-eole.ac-dijon.fr/doc/zephir/features/epic6.html#e6-2-liaison-entre-un-minion-saltstack-et-un-server-zephir
L’application Zéphir devrait avoir un lien logique entre les instances de Server et les machines (“minions”) appairées avec le processus salt-master.
La cinématique classique décrite dans la documentation (https://docs.saltstack.com/en/latest/topics/tutorials/walkthrough.html#using-salt-key) indique que le minion effectue une demande d’appairage sur le master et que celui ci accepte (ou non) la demande via la commande salt-key.
Cette cinématique est elle compatible avec le mode de fonctionnement attendu de Zéphir ? L’initiative de l’appairage ne devrait il pas venir du Zéphir ?
h2. Proposition
Statuer sur la procédure d’appairage via Salt d’une machine avec Zéphir puis implémenter la solution retenue.
h3. Possibilité 1 (appairage "classique" SaltStack à l'initiative du minion) Procédure proposée (en accord avec la stratégie classique d’appairage SaltStack)
# L'utilisateur L’utilisateur configure sur sa nouvelle machine son "minion" “minion” SaltStack et le fait pointer vers la machine Zéphir (ou le salt-master utilisé par Zéphir)
# Le "minion" “minion” envoie sa clé publique au salt-master et attend son approbation
# Sur le Zéphir, l'utilisateur l’utilisateur créait un nouveau :ref:`server` Server sur Zéphir (avec le bon :ref:`server-model` ServerModel associé)
# L'utilisateur "appaire" L’utilisateur “appaire” manuellement son instance :ref:`server` Server avec une des clés publiques de "minion" “minion” en attente d'approbation d’approbation
# La machine "minion" “minion” est désormais pilotable via le Zéphir
Ce mode de fonctionnement pose la question de l'affichage des demandes d'approbation. Quid du filtrage en fonction des droits d'accès ?
L'étape 4 devrait concentrer la majeure partie du travail de réflexion/développement.-
h3. Possibilité 2 (appairage à l'initiative du master)
# Sur le Zéphir, l'utilisateur créait un nouveau :ref:`server` sur Zéphir (avec le bon :ref:`server-model` associé)
# Le service `saltmaster` réagit à la création de ce nouveau :ref:`server` et créait un paire de clés cryptographiques à destination du minion. La paire de clé est dédiée/liée au :ref:`server`.
# L'utilisateur récupère cette paire de clés via l'interface et la déploie manuellement sur la machine avec le minion
Cette procédure découle du mode de déploiement `preseed` proposé dans la documentation SaltStack. Voir https://docs.saltstack.com/en/latest/topics/tutorials/preseed_key.html.
L’étape 4 devrait concentrer la majeure partie du travail de réflexion/développement.
D’autres méthodologies sont possibles, notamment via un génération d’une paire de clés “pré-approuvées” directement sur le Zéphir et un déploiement manuel sur la machine “minion”.
h2. Critères d'acceptation
* On peut faire le lien entre un “minion” appairé sur le salt-master et un Server sur l’application Zéphir
h2. Documentation
https://dev-eole.ac-dijon.fr/doc/zephir/features/epic6.html#e6-2-liaison-entre-un-minion-saltstack-et-un-server-zephir