Scénario #22026
Mis à jour par Emmanuel GARETTE il y a plus de 6 ans
h2. Contexte Fonctionnalité
L'application L’application Zéphir devrait avoir un lien logique entre les instances de server Server et les machines ("minions") (“minions”) appairées avec le processus salt-master.
Il existe plusieurs cinématiques possibles :
* 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 serveur génère minion effectue une demande d’appairage sur le master et que celui ci accepte (ou non) la clé : https://docs.saltstack.com/en/latest/topics/tutorials/walkthrough.html#using-salt-key
* demande via la commande salt-key.
Cette cinématique est elle compatible avec le mode de fonctionnement attendu de Zéphir génère la clé : https://docs.saltstack.com/en/latest/topics/tutorials/preseed_key.html ? L’initiative de l’appairage ne devrait il pas venir du Zéphir ?
h2. Proposition
Statuer sur la procédure d'appairage d’appairage via Salt d'une d’une machine avec Zéphir puis implémenter la solution retenue.
h3. Possibilité 1 le serveur génère la clé (appairage "classique" SaltStack à l'initiative du minion)
# L'utilisateur configure sur sa nouvelle machine son "minion" SaltStack et le fait pointer vers la machine Zéphir (ou le salt-master utilisé par Zéphir)
# Le "minion" envoie sa clé publique au salt-master et attend son approbation
# Sur le Zéphir, l'utilisateur crée créait un nouveau server :ref:`server` sur Zéphir (avec le bon server-model :ref:`server-model` associé)
# L'utilisateur "appaire" manuellement son instance server :ref:`server` avec une des clés publiques de "minion" en attente d'approbation
# La machine "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 le Zéphir génère la clé (appairage à l'initiative du master)
# Sur le Zéphir, l'utilisateur créait un nouveau server :ref:`server` sur Zéphir (avec le bon server-model :ref:`server-model` associé)
# Le service saltmaster `saltmaster` réagit à la création de ce nouveau server :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 server. :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
Une 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 traitement pourrait être automatisé travail de réflexion/développement.
D’autres méthodologies sont possibles, notamment via un script (comme c'est génération d’une paire de clés “pré-approuvées” directement sur le cas dans le Zéphir actuel). Cette solution permet de garantir que et un déploiement manuel sur la personne qui appaire le serveur à vraiment le droit de le faire mais nécessite un ensemble d'action non automatisé par Salt. machine “minion”.
h2. Critères d'acceptation
* On peut appairer un server sur l'application Zéphir et faire le lien entre un "minion" “minion” appairé sur le salt-master et un server. 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 L’application Zéphir devrait avoir un lien logique entre les instances de server Server et les machines ("minions") (“minions”) appairées avec le processus salt-master.
Il existe plusieurs cinématiques possibles :
* 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 serveur génère minion effectue une demande d’appairage sur le master et que celui ci accepte (ou non) la clé : https://docs.saltstack.com/en/latest/topics/tutorials/walkthrough.html#using-salt-key
* demande via la commande salt-key.
Cette cinématique est elle compatible avec le mode de fonctionnement attendu de Zéphir génère la clé : https://docs.saltstack.com/en/latest/topics/tutorials/preseed_key.html ? L’initiative de l’appairage ne devrait il pas venir du Zéphir ?
h2. Proposition
Statuer sur la procédure d'appairage d’appairage via Salt d'une d’une machine avec Zéphir puis implémenter la solution retenue.
h3. Possibilité 1 le serveur génère la clé (appairage "classique" SaltStack à l'initiative du minion)
# L'utilisateur configure sur sa nouvelle machine son "minion" SaltStack et le fait pointer vers la machine Zéphir (ou le salt-master utilisé par Zéphir)
# Le "minion" envoie sa clé publique au salt-master et attend son approbation
# Sur le Zéphir, l'utilisateur crée créait un nouveau server :ref:`server` sur Zéphir (avec le bon server-model :ref:`server-model` associé)
# L'utilisateur "appaire" manuellement son instance server :ref:`server` avec une des clés publiques de "minion" en attente d'approbation
# La machine "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 le Zéphir génère la clé (appairage à l'initiative du master)
# Sur le Zéphir, l'utilisateur créait un nouveau server :ref:`server` sur Zéphir (avec le bon server-model :ref:`server-model` associé)
# Le service saltmaster `saltmaster` réagit à la création de ce nouveau server :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 server. :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
Une 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 traitement pourrait être automatisé travail de réflexion/développement.
D’autres méthodologies sont possibles, notamment via un script (comme c'est génération d’une paire de clés “pré-approuvées” directement sur le cas dans le Zéphir actuel). Cette solution permet de garantir que et un déploiement manuel sur la personne qui appaire le serveur à vraiment le droit de le faire mais nécessite un ensemble d'action non automatisé par Salt. machine “minion”.
h2. Critères d'acceptation
* On peut appairer un server sur l'application Zéphir et faire le lien entre un "minion" “minion” appairé sur le salt-master et un server. 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