documentation/compte_rendus/2018_04_06.md

92 lines
3.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

# Réunion développement re2o
Présents :
* Chirac
* Charlie
* Grizzly
* Esum
A noter que la réunion na 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 dimport 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 lembryon 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 daccord là dessus.
### 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
* enregistrement de lemplacement des switchs et génération de la map de la
topologie du réseau
* affichage pretty des switchs (equivalent de swicths2 pretty)
* 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 lembyron présent dans re2o (nftable ? )
* generation de la conf des switchs, code modulaire permettant de générer de la
conf pour dautre modèles que des hp. Voir une solution existante ?
* adherent : gestion de la creation des homes, à inclure dans re2o-tools
Enfin, on a débattu un peu sur la sécurité. Dans re2o, il ny a quun 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 sagit de laccès web re2o, et des
accès serveurs (sudo en particulier).
Lautre 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 daccord pour dire que les gens ne sy
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 nest pas le wifi. Ce nest pas
satisfaisant daprès Charlie, cela naugmente pas la sécurité, en effet cest
toujours le même mot de passe entre laccès serveur, laccès gitlab ou laccès
mail, mais surtout les accès serveurs sudo qui sont la pièce critique, comme
actuellement au CRANS.
On peut forcer lauthentification 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 laccès re2o-web qui serait toujours le même mot
de passe.
On peut allier les 2 solutions; forcer lauth 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.