-------------------------------------------------------------------------------- CTE-25 3 septembre 2013 -------------------------------------------------------------------------------- Agenda: https://indico.in2p3.fr/conferenceDisplay.py?confId=8713 Présents -------- JC. Chevaleyre (JCC), J.Pansanel (JP), M.Aljogami (MA), S.Pop (SP), G.Romier (GR), B.Levy (BL), G.Mathieu (GM), F.Chollet (FC), C.Biscarat (CB), P.Gay (PG), D.Bouvet (DB) Tour de table ------------- JP propose d'ajouter un point sur une question récente de sécurité. Le point est intégré à la discussion "sécurité" dans l'agenda du jour. actualités : monitoring ----------------------- BL présente les actualités du groupe et les chantiers en cours (-> slides en ligne) Précisions/discussion : Les tests de l'update 22 sont OK sur la machine de test, le plus gros problème observé étant la différence de résultats de sondes. Pour précision, cet update est l'update du produit "SAM-Nagios fourni par EGI. L'équipe monitoring a été en contact avec les développeurs de SAM-nagios sur les pbs d'installation. La réinstallation va nécessiter un downtime conséquent : il est important de prévenir les sites FG, et de vérifier avec EGI quelle est la marche à suivre pour que cette période "non testée" soit prise en compte dans les calculs de disponibilité d'une part, et dans les procédures ROD/COD d'autre part (action sur Gilles). Il ne sera probablement pas possible d'utiliser la nagbox de test en "remplacement" pour la durée du downtime, pour des questions d'ACL à régler actualités : cloud ------------------ L'été a été calme, avec seulement 2 réunions tenues sur 4, et peu de présence. Il y a une soumission d’articles en cours pour les journées SUCCES pour présenter la démarche Cloud et les solutions techniques. La deadline est le vendredi 6. Cet article permettra d’entériner le travail en cours, et de poser les bases de l'action de France Grilles en matière de Cloud. (l'article est sur la page Cloud du wiki opérations) : https://forge.in2p3.fr/projects/francegrilles-ops/wiki/Cloud Sur le plan technique, les dernières avancées sont les travaux de Mattieu Puel au CC sur l'utilisation de cloud-init avec libcloud. Les résultats sont également disponibles sur le wiki. Par ailleurs, s'est tenue le 27 août à l'IDRIS une réunion à laquelle France Grilles était conviée, sur la mise en place d'une plateforme cloud pour l'IFB (Institut Français de Bioinformatique), récemment créé. L'infrastructure est a priori séparée des infrastructures France Grilles, mais il peut y avoir une base de collaboration autour de l'échange d'expertise et d'information sur les problématiques de fédération. Retour sur le pb de sécurité IPHC du 06/08 ------------------------------------------ JP : point sur le soucis sécurité avec Alice au début du mois d'août. De nombreuses connexions de type p2p vers des IPs non académiques on été détectées. Après analyse, il semble qu'il s'agisse d'un dysfonctionnement du système utilisé par Alice pour la récupération de son soft, qui est basé sur BitTorrent. L'un des soucis remonté a été le fait que les alertes arrivent souvent trop tard pour permettre d'analyser ce qui se passe, notamment dans le cas de jobs courts (les alertes Znet sont remontées après 15mn). Ce genre de problème est difficile à régler, car bannir l'utilisateur demandait le banissement du certificat utilisé par les jobs pilotes, donc en bloquant une grande partie des utilisateurs d'Alice. le problème s'est discuté en direct entre Alice et les sites. La réaction côté Alice a été de demander le blocage des IPs côté firewall des sites. Le même problème a été observé sur d'autres sites (LPC, IPNL). La solution appliquée a été le filtrage des IPs en sortie. GM va faire remonter l'info côté CSIRT pour savoir s'il y a eu une discussion à ce sujet à plus haut niveau. FC va faire de même auprès du GDB. Il y aurait un intérêt à faire une recette sur ce pb au cas où. à terme, ce genre de problèmes pourrait être réglé par l'utilisation de glexec et argus. Etude de risques SSI -------------------- Suite à la réunion sécurité France Grilles qui s'est tenue au LPC en juin, de nombreuses discussions avec la DSI et l'ANSSI ont montré l'intérêt de mener au sein de France Grilles une étude de risques afin d'évaluer de manière profonde et objective les risques auxquels nous sommes potentiellement ammenés à répondre, ainsi que pour avoir une base commune au niveau des partenaires pour savoir quel est le but de la sécurité dans France Grilles. Nous avons comme élément de départ l'étude de risque faite dans WLCG. L'analyse proposée au niveau de France Grilles est menée en suivant la méthodologie EBIOS, préconisée par l'ANSSI, et est dans un premier temps pilotée par Gilles. Il s'agit d'une démarche progressive pour l’analyse en caractérisant tout d'abord le contexte, puis les bien à protéger, les événements redoutés et les scénarios de menaces, pour aboutir à une cartographie des risques. Questions/discussions : - Quel doit être le périmètre de l’étude ? s'agit-il des infrastructures, des services, de FG dans son ensemble ? La réponse est dans "comment définit-on France Grilles"... autrement dit, on n'est pas sortis :-) FC propose de reprendre de nombreux éléments de l'étude WLCG, mais la limite à cela est méthodologique, l'ANSSI et les RSSI français ayant quelques soucis d'interprétation avec la norme et le référentiel proposé. Le cas "français" est également assez spécifique, car notre organisation n'est pas similaire aux autres NGIs ou participants à WLCG. Cela n'empêche pas que l'analyse de risques FG doit être complémentaire à l'analyse WLCG. - identification des biens essentiels : se concentrer sur les services fournis, ou bien intégrer d'autres dimensions, comme l'expertise ? France Grilles n'est pas propriétaire de tous les biens. JP: dépend du contrat qu'on a avec les utilisateurs - garanties à définir FC: partagée sur le fait de tout intégrer, au risque de faire un travail énorme. Les biens = les ressources (utilisation à bon escient des ressources fournies) GR: vérifier si ce n'est pas propre qu'au HEP FC: aussi la question de la réputation Se pose aussi la question de la définition claire des responsabilités (FG, les VOs, les utilisateurs, les sites, les tutelles...) D'une manière générale, la clarification des responsabilité devrait apparaitre comme un "effet de bord" bénéfique de l'étude. En cela, la démarche est aussi importante que le résultat. - Définition du "risque" : doit-on considérer les risques pour France Grilles en tant que structure, ou de manière plus large ? Autrement dit, est-il pertinent de réfléchir dans cette étude aux risques encourus par d'autres entités s'il arrive tel ou tel problème à France Grilles ? FC: doit être plus large que FG car implique beaucoup plus que FG seulement. GR: si l'analyse se veut globale, elle doit peut-être se présenter comme un aggrégat des analyses de risques des différents composants de FG + l'analyse spécifique à FG. Le but final reste d'extraire les risques non négligeables pour lesquels il n'y a pas de moyens actuellement, et sur lesquels il faut agir. Gilles attend maintenant un retour sur le document de la part de D.Crochemore (ANSSI) et L.DiBenedetto(RSSI du CNRS). Un point régulier sur les avancées de cette étude sera fait aux prochaines réunions du CTE. support opérationnel dans FG ---------------------------- Gilles présente les questions à soulever (slides en ligne) SP: il faudrait ajouter et prendre en compte le support opérationnel existant au niveau des VO. Ex pour biomed, liste de shifts, liant utilisateurs et sites. DB: le pb pour les utilisateurs se pose car dans GGUS il n'y a pas d'entrée France Grilles, mais des entrées VO. Pour de nombreuses VO il n'y a pas de shifts ni de support dédié, donc FG peut avoir une plus-value. GR: chaque site a un peu sa méthode pour faire du support à ses utilisateurs, selon la VO. FC: on n'a pas les moyens de juxtaposer la liste des groupes d'expertise + un support opérationnel en parallèle. Or une infrastructure ne peut pas fonctionner sans support. N groupes d'expertise faisant chacun du support dans son domaine, ce n'est pas viable. Il faut un support central, au moins au niveau de l'interface. Il faudrait donc abandonner ce découpage en groupes d'expertise, et les regrouper en une équipe support avec un seul point d'entrée. JP: cela simplifierait beaucoup l'organisation visible. GM: groupes d'expertises peuvent rester en tant que "groupes d'intérêt". ou "groupe d'administrateurs de services" (e.g. pour monitoring et accounting). DB: rien n'empêche d'avoir un gros pavé support, et de gardé les groupes derrière. JP/CB: le point d'entrée central pourrait être un 1er niveau qui aiguille les demandes. Les groupes d'expertise pourraient agir en niveau 2. GR: bien d'avoir un point d'entrée unique, mais il faudrait tenir compte de ce qui existe déjà : GGUS au niveau EGI, ce qu'il existe sur les sites, les support en place dans DIRAC... il faut réfléchir à faire quelque chose de cohérent. C'est plus compliqué que si on construisait tout à partir de rien. La difficulté est de ne pas détruire les systèmes qui existent, mais de les fédérer. PG: pour DIRAC il n'y a pas de vrai support utilisateur en place, à part la liste d'admins. Il peut y avoir un besoin pour l'instance nationale, indépendant des besoins de support sur l'outil DIRAC lui-même. GM: il peut y avoir des liens entre les supports d'outils et les supports d'utilisation de cet outil. DB: le côté organisation est assez établi avec les modes d'expertise. Maintenant c'est plus une question de moyens et d'outils. FC: il y a beaucoup de confusion dans le modèle actuel, ex: service monitoring, expertise monitoring, infrastructure monitoring... beaucoup de découpage. DB: il y a besoin de ce découpage mais pas forcément besoin de le montrer partout. CONCLUSIONS : Sur les bases de la discussion de ce jour, Gilles va revenir vers le CTE avec une proposition d'organisation visant à : - fédérer une activité "support", permettant de rendre visible cette facette vers l'extérieur des opérations mais aussi en interne - proposer une organisation interne pour que le modèle en question ne résulte pas en un N-ième changement de modèle - poser une base de réflexion pour déterminer les outils dont nous aurions besoin (XGUS, liste, shifts...) travail commun LCG-FR et France Grilles --------------------------------------- GM présente le travail en cours sur une cartographie de services grille en France (document en ligne). Ce travail est le fruit d'une réflexion initiée dans le printemps et exposée aux dernières rencontres LCG-France au LLR en mai. Questions/discussion : GR: offre de service : on ne peut pas mettre sur le même plan l'offre vers les utilisateurs et l'offre vers les VOs. Sur le schéma se pose la question de la pertinence d'une case "RH". Elle doit sans doute être présente mais placée différemment car ce n'est pas un "service". Points à modifier sur le schéma : - Mettre les RH et les infrastructures "en dessous" du schéma - Coordination & Pilotage : supprimer "pilotage" - Infrastructures de services internes : supprimer "infrastructure" - simplifier le cadre "support opérationnel" (une seule case "support") - proposer un code couleur pour les services mutualisés ou "à cheval" entre les deux Prochaine étape : établir un graphe de dépendance entre les différent "services" prochaines réunions ------------------- Prochain CTE le 8 octobre. Divers ------ RAS. ------------------------------------------------------------------------------- ACTIONS ------------------------------------------------------------------------------- https://forge.in2p3.fr/projects/francegrilles-ops/wiki/CTE_actions [Gilles] vérifier au niveau d'EGI les implications d'un downtime sur la nagios box pour l'update 22 [Frédérique] passer l'info en GDB des problèmes sécurité rencontrés par les sites Alice [Gilles] passer l'info à EGI CSIRT des pbs sécurité rencontrés par les sites Alice [Gilles] passer l'info à EGI CSIRT des pbs sécurité rencontrés par les sites Alice [Gilles] faire au CTE une proposition d'organisation pour le support opérationnel [Gilles/Frédérique] Retravailler la cartographie de services FG-LCGFR pour faire une nouvelle proposition au CTE