Table des matières

2020/03/09 (datacenter)

Pré-réunion ^_^

Ça cause SAML, Keycloak et Nextcloud (genre https://stackoverflow.com/questions/48400812/sso-with-saml-keycloak-and-nextcloud )

Heure de fin prévue : 19h00

Contours

Définir qu'est-ce qui rentre dans le cadre de la structure qu'on met en place ? Est-ce que la structure se concentre sur la gestion du rack, le routage et l'infrastructure ?

Administrativement

Gérer la structure

Qui s'appellera pas chez mémé ni 42u mais qu'il faudra trouver.

Pour tierce le nom est important pour donner un peu le ton des choses et dans tout ce qu'on fais je trouve que l'aspect « détendu du slip » est important.

Pour les autres moins.

Soit.

Nombre d'accès au data center.

Les contours de la structure

La gestion de la baie (c'est très vague et tout ce qui est sur ce pad tente à le définir mieux).

La prise en charge du routage (vois plus bas)

La gestion d'un stock de matériel de remplacement

Il est a noter que les communications mobiles sont souvent inaccessibles dans un DC (un téléphone de secours peut être proposé par le DC)

Comment définir les « gardes » pour garantir l'opérationnel de la baie.

Définir qui sont les noms sur les contrats avec le DC et les signer.

Recevoir et payer les factures.

Recevoir et traiter les demande de colocations de chaque membre

Définir des contrats, tarifs, conditions et accès au DC pour chaque membre.

Chaque membre gère ses serveurs. Ce n'est pas la structure qui en est responsable.

Concernant les accès, il est peut-être possible de demander qu'un mail soit envoyé si un « bouton d'accès » est utilisé.

Envoyer le factures et suivre les paiements de chaque membre

Recevoir et traiter les requêtes judiciaires (sauf si c'est Neutrinet qui met ses IPs)

Attribuer les IPs

Définir le Service Level Agreement (SLA) des membres de la baie.

Techniquement

Accès root.

Chez Neutrinet les clés sont là : https://gitlab.domainepublic.net/Neutrinet/infra/-/blob/master/group_vars/all

Comment donner et retirer un accès root. Proposition de HgO:

Les pleins pouvoirs, chez Neutrinet en tout cas, s'accordent sur base d'une confiance humaine que nous n'avons jamais formalisé et … que nous ne souhaitons probablement pas le faire.

Par exemple, de vielles clés sont encore présentes, mais des clés de gens en qui nous avons confiance et rien n'est automatisé pour supprimer ces clés.

Les choses qui concerne l'infrastructure sont traitées dans le hub-infra.

Il est peut-être utile de définir des choses simples, claire et efficaces dans la droite ligne du Keep It Stupid and Simple.

La liste des root doit être clairement rendue publique et si quelqu'un doit être ajouté à cette liste TOUT les membres de la liste doivent donner leur accord puisque seul un root peut donner un droit root à une nouvelle personne.

Peut-être également publier les connexions à cette ou ces machines dans l'idée d'afficher une forme de monitoring publique de « qui se connecte à quoi ». C'est un peu l'automatisation du channel #ops sur chat.neutrinet.be.

Un constat … difficile de « protéger les membres » des problèmes techniques (accès root à un méchant, bug dans un protocole, mise à jours oubliée, porte dérobée dans un firmware,…) par une voie administrative (contrats, assurances,…).

Une forme de protection « technique », par exemple signer une config BGP et avertir si une config modifié est poussée.

Routage

Il faut peut-être se demander si se référer à des certifications du genre CISCO CCNA sont un prérequis.

Il est possible de faire du routage BGP dans les switchs de la baie.

Par exemple, un des problèmes auxquels « on » pourrait-être confrontés : une attaque DDOS

La machine qui s'occupera du routage sera une machine essentielle tant pour des questions d'infrastructure que pour des questions de sécurité

Il est a noter que ce sera deux VMs pfsense sur un cluster proxmox de 2 serveurs et d'un ordinateur supplémentaire nécessaire au quorum. Cela amène la question de savoir si les non-neutrinetiens sont limité à ces VMs de routage ou si cela descend jusqu'au barebone.

Définir qui aurait accès à la machine qui gère le routage.

Si Neutrinet : actuellement 7 personnes sont sudoers MAIS seulement tharyrok et peut-être e-jim sont capable actuellement de gérer BGP ou le routage. Ceci dit … c'est le genre de choses qui ne changent pour ainsi dire jamais.

Définir les accès et procédures des différentes structures

Au même titre qu'un VPN reçoit son IPv4, son /64 IPv6 et ses gateways … ou il y a autre chose ?

Formation commune autour des sessions BGP

À planifier.

Mettre en place du monitoring

Vous allez dire que ça va de soit… mais c'est quelque chose qu'il faudra faire.

Gestion des serveurs

Chacun s'occupe de ses propres serveurs

À distance, ça va de soit … mais est-ce qu'il y a des « accès de secours » à prévoir ? Genre un VPN qui donnerait accès aux IPMI, Drac et autres ?

Physiquement celà dépendra un peu du genre d'accès au DC et soit il y a de l'autonomie soit il faut un chaperon à chaque passage.

Solidarité pour les procédures d'urgences à la demande de la structure. Travail défrayé par la structure ou 42U

Il y a une différence entre la structure et 42u ?

Éventuellement gestion d'un stock de secours utilisable par les structures (alimentation, disque dur, serveurs, …)

Où se trouverait ce stock ?

Gestion des switchs

Il y aura des switchs (si possibles 2 pour la redondance) et il serait bon de pouvoir y faire des VLANs. Donc ce seront également des machines disposant d'accès « root ».

Gestion commune des mots de passes.

Avec les Gnuragistes nous avons mis en place GPG, Gopass et un répot gitea pour partager nos secrets.

Chez Neutrinet on a commencé aussi mais c'est pas fini.

Avis personnel(s)

tierce :

J'ai le sentiment de ne pas avoir été entendu sur le fait de commencer à 350€ / mois chez Verixi pour nous (thary, hgo, tierce) et vous (denis, kenny, ?) et profiter de la mise en place de nos serveurs (de prod pour nous) et de test / Nubo pour vous et « prendre des notes » pour définir petit à petit les questions / réponses / procédures et autre. N'ayant pas d'expérience en DC et encore moins en « gestion commune » il m'est difficile d'avancer sur la base seule de mon expérience et de mon imaginaire. J'en attendais beaucoup trop de « l'esprit bidouille » mais force est de constater que je me suis trompé. Ne me faites pas dire ce que je n'ai pas dis, « bidouille » ne veut pas dire manque de sérieux dans les objectifs à atteindre. C'est le chemin qui était à mes yeux la « bidouille » pas la destination.