10:01
---- Gabriel Detraz a écrit ----
Salut à tous,
Pour ceux qui n’étaient pas là, voici ce qui s’est dit (de mémoire, les présents
corrigeront) vendredi.
Présents : Chirac, Charlie, Grizzly et Esum
A noter que la réunion n’a pas durée très longtemps à cause du départ de Charlie :
Point sur ce qui a été fait niveau infra : - mise en place de re2o-server, vm avec un
serveur web apache de dev et bdd sur thot (postgresl)
- mise en place de re2o-ldap, contenant le ldap de re2o
- mise en place de re2o-services, contenant les services dhcp, dns notamment.
- import de la bdd actuel avec un script d’import bien avancé, permettant de faire des
tests ( presque tout passe, sauf les serveurs disposant de la même mac sur plusieurs VLAN
: https://gitlab.crans.org/nounous/scripts/blob/master/re2o/import_crans.py )
Ces vm sont sur adh/adm.
Charlie suggère de rajouter l’embryon de parefeu sur services, de créer des vlans dédiés
en dehors de adm avec des id élevés ( > 30 ? ); enfin de tester sur ces vlan un mini
réseau, avec également la vm re2o-services qui servirait de routeur. Tout le monde semble
d’accord là dessus.
Hmm de mémoire 5-1 m'avait dit que son "embryon" était operationel. A
confirmer ceci-dit
Ce qui a été fait niveau dev : - factorisation du système de gestion des acl
- portages de scripts divers mais essentiels ( chsh, chgpass, unifi-ap-sync, dernière
connexion) via des commandes django et des appels aux forms et aux validations des models
Quel en est l'utilité ? c'est une commande qu'on lance depuis django manage.py
? On peut l'appeler depuis l'extérieur ?
- enregistrement de l’emplacement des switchs et génération de la map de la topologie du
réseau
- affichage pretty des switchs (equivalent de swicths2 pretty)
Fort pretty en effet
- fonction de ménage cableur
- possibilité d’éditer la liste des shells sans passer par le /admin
- model borne wifi spécifique
Ces taches ont une criticité diverse. Sur le reste, il faut avancer dans le code, on fait
grosso modo la liste des chantiers. En critique/prioritaire, il y a : - firewall, à partir
de l’embyron présent dans re2o (nftable ? )
Cf comment au dessus
- generation de la conf des switchs, code modulaire permettant de générer de la conf pour
d’autre modèles que des hp. Voir une solution existante ? - adherent : gestion de la
creation des homes, à inclure dans re2o-tools
C'est-à-dire la creattion des homes ? Vous pouvez pas le faire comme c'est fait en
ssh actuellement ?
Enfin, on a débattu un peu sur la sécurité. Dans re2o, il n’y a qu’un seul login/mdp pour
tout.
Avantages :
- plus simple pour les users à comprendre et à retenir comme système
- permet d’éviter la fraude, en effet, il est moins facile de filer son mdp de son compte
crans en entier à un « ami »
Inconvénient : - le mdp est le même partout, cela peut poser un problème de sécu en
particulier pour les admin.
On identifie les fonctions sensibles : il s’agit de l’accès web re2o, et des accès
serveurs (sudo en particulier).
L’autre problème concerne la phase transitoire, il va falloir gérer les mdp legacy des
machines, mais il « suffira » de tweaker un peu auth.py au moins temporairement pour ça.
Plusieurs solutions possibles :
Avoir un second compte; on est tous d’accord pour dire que les gens ne s’y tiendront pas,
cette solution semble trop pénible.
Pour les admin ou pour les gens qui le souhaitent, on pourrait mettre en place un second
mot de passe pour tout ce qui n’est pas le wifi. Ce n’est pas satisfaisant d’après
Charlie, cela n’augmente pas la sécurité, en effet c’est toujours le même mot de passe
entre l’accès serveur, l’accès gitlab ou l’accès mail, mais surtout les accès serveurs
sudo qui sont la pièce critique, comme actuellement au CRANS.
On peut forcer l’authentification par clef ssh pour les admin, comme ça si un mot de
passe est compromis, les accès serveurs ne le sont pas. Problème : cela ne résout pas le
problème de l’accès re2o-web qui serait toujours le même mot de passe.
Moi forcer l'auth ssh ça me gêne pour plusieures raisons mais vous avez peut être des
solutions :
1) si tu veux faire un sudo..., tu le fais comment sans rentrer ton mdp ? Tu peux
configurer sudo pour être basé sur ta clé ssh ? Parce que si tu dois taper ton mdp, ça
pert de son intérêt.
2) si t'as ssh sur un serveur X et tu veux ssh sur un serveur Y(exemple de
j'accède aux serveurs depuis l'extérieur donc en passant par un serveur), tu fais
comment ? Tu laisses une clé privé dans ton home ? Je suis pas fan de laisser
n'importe qui qui est sudo la possibilité de se connecter avec mon compte (même si
c'est vrai tu peux chiffrer ta clé, permettre de la voir, c'est un premier pas
vers l'insécurité. Et si tu chiffres, tu met un mot de passe, et en pratique ce sera
le même que re2o je pense)
On peut allier les 2 solutions; forcer l’auth par SSH + second mot de passe pour les
admin permettant de récupérer leurs droits sur re2o-web, ce qui permet de couvrir à peu
près tout. Le débat reste ouvert.
Sachez que vous ne pourrez pas forcer l'auth ssh partout. Je sais que chez nous, par
experience, c'est mort pour que tous le monde ait une clé ssh. Et je pense aussi pour
que les gens s'emmerdent avec deux mots de passe (même les admins). Ça va plus fermer
les portes aux curieux qui veulent découvrir le rézo qu'etre bénéfique je pense (pour
rennes en tout cas).
Donc même si je suis d'accord avec vous sur le principe, en pratique, ce serait cool
de laisser la possibilité de continuer comme c'est actuellement
Voilà à peu près ce qu’on a dit,
Cordialement,
— Chirac