RenPar’18 / SympA’2008 / CFSE’6 Fribourg, du 11 au 13 février 2008
Support d’organisations virtuelles au sein d’un système d’exploitation pour la grille
Sylvain Jeuland, Yvon Jégou, Oscar David Sánchez, Christine Morin
IRISA/INRIA Rennes, Campus de Beaulieu, 35042 RENNES Cedex - France {Sylvain.Jeuland, Yvon.Jegou, Oscar.Sanchez, Christine.Morin}@inria.fr
Résumé
En dépit de la popularité croissante des grilles, les organisations virtuelles (VO) ne constituent pas en- core une technologie courante dans les environnements informatiques modernes. En effet, la gestion des VO est complexe et il est difficile d’assurer leur isolement ainsi que celui des utilisateurs. XtreemOS est un nouveau système d’exploitation (OS) pour les Grilles qui fournit un support natif pour les VO.
Les ressources de calcul considérées s’étendent des grappes de calcul aux téléphones mobiles. Afin de gérer des ordinateurs répartis sur tout le réseau, les mécanismes de sécurité et de gestion des ressources sont étendues. Afin de modéliser les VO, le système d’exploitation XtreemOS intègre un ensemble de services et de protocoles de niveau grille au sein de chaque machine par des extensions et une configu- ration adéquate du système d’exploitation Linux.
Mots-clés : XtreemOS, Grille, Organisation virtuelle (VO), Sécurité
1. Introduction
Les technologies de grille sont de plus en plus répandues dans le domaine du calcul scientifique et font appel à desorganisations virtuelles (VO)pour la gestion d’un grand nombre d’utilisateurs et de nœuds de calcul. Une VO rassemble plusieurs organisations dispersées géographiquement qui mettent à dis- position des ressources, des capacités de calcul et des informations pour atteindre un objectif commun.
Que ce soit dans des applications scientifiques ou commerciales, ce type d’organisation permet à un ensemble d’utilisateurs de partager des nœuds de calcul et des ressources. Les VO s’inscrivent très bien dans le contexte économique car elles permettent de regrouper pendant un temps limité plusieurs dé- partements ou organisations afin de réaliser un objectif commun. Une fois celui-ci atteint, la VO peut se dissoudre, contrairement à la grille.
XtreemOS1est un projet européen qui a pour objectif de concevoir un système d’exploitation pour les grilles. XtreemOS vise diverses plateformes allant des grappes de PC aux dispositifs mobiles (PDA, téléphone mobile).
Le support de VO de XtreemOS [3] permet de gérer diverses contraintes définies par un cahier des charges rédigé suite à l’étude d’une vingtaine d’applications. Pour les supporter, XtreemOS offre une boîte à outils de gestion des VO qui peut être configurée différemment selon les besoins. Le travail concernant le support des VO est actuellement en cours. Un prototype de base existe mais plusieurs fonctionnalités doivent encore être implémentées.
Comme XtreemOS s’appuie sur le système d’exploitation Linux, il peut utiliser certains des outils déjà présents dans le système. Pour cela, il est nécessaire de les améliorer et de les configurer afin de pouvoir interagir avec la grille tout en préservant les qualités d’efficacité, de flexibilité et de compatibilité. C’est en coordinant l’ensemble de ces outils que nous pouvons fournit un support de VO efficace. Comme les outils de bases nécessaires existent déjà dans UNIX, les administrateurs et les utilisateurs n’ont pas besoins d’apprendre de nouvelles interfaces. De plus il n’est pas nécessaire de modifier les applications existantes car XtreemOS maintient la compatibilité POSIX.
1Projet Intégré FP6 de la Commission Européenne IST2006-0033576 XtreemOS. http ://www.xtreemos.eu
Dans la section 2, nous présentons une vue d’ensemble de l’approche XtreemOS. La gestion des VO dans le prototype est détaillée dans la section 3 et la section 4 porte sur la mise en œuvre du prototype ainsi que son implémentation au niveau de la grille.
2. Vue d’ensemble de l’approche XtreemOS 2.1. Défis
À partir des exigences d’applications scientifiques et commerciales [9] ainsi que de l’état de l’art concer- nant les VO, plusieurs défis à relever ont été définis pour la conception d’un support aux organisations virtuelles dans le système XtreemOS comme l’interopérabilité avec les systèmes, l’authentification, le contrôle d’accès, l’isolement, l’audit et la gestion dynamique des VO.
2.1.1. Interopérabilité avec d’autres modèles existants
Il existe plusieurs manières de gérer une VO et différents modèles de sécurité. Par exemple il existe plusieurs façons d’identifier les utilisateurs (i.e. les certificats d’utilisateurs X.509, support Shibboleth2) ou encore de représenter les attributs de sécurité (i.e.proxy certificates3, SAML tokens4). De même, plu- sieurs protocoles d’échange d’informations (push,pull,agent) et plusieurs modèles de politiques sont disponibles. XtreemOS doit offrir un support générique permettant d’instancier les différents modèles d’organisations virtuelles et doit également être compatible avec les différents mécanismes locaux de sécurité (i.e. Kerberos) sans les remplacer.
2.1.2. Isolement, contrôle d’accès et audit
XtreemOS doit offrir un accès sécurisé aux objets système (i.e fichiers, processus) en fonction des poli- tiques de la VO. Le système d’exploitation permet de cacher les identités des utilisateurs, de protéger les fichiers et les processus. L’isolement des performances garantit qu’une ressource partagée entre plu- sieurs VO fournira une qualité de service garantie à tous les utilisateurs sans favoriser l’un d’entre-eux au détriment des autres. Il doit être possible de surveiller et de tracer l’accès aux ressources comme les objets système tout en s’assurant qu’on puisse à tout moment consulter ces informations.
2.1.3. Gestion dynamique des VO et passage à l’échelle
Un nœud peut partager ses ressources entre de nombreux utilisateurs de plusieurs VO différentes. Ce passage à l’échelle rend complexe la gestion des fichiers de configuration locaux lorsque les VO sont créées ou modifiées de manière dynamique. En effet, garantir la cohérence de ces fichiers contenant des informations sur les utilisateurs et les ressources est difficile dans les grilles de très grande taille. Il est préférable d’éviter d’avoir à modifier de tels fichiers de configuration à chaque fois qu’un utilisateur se joint à ou quitte une VO.
2.1.4. Authentification simplifiée
Les systèmes d’authentification de la grille sont indépendants de ceux des systèmes d’exploitation. Les intergiciels de la grille tels Globus5et Glite6manipulent deux identités indépendantes. L’identité locale intervient au niveau du système d’exploitation d’où a été soumise l’application et de la machine qui exécute l’application considérée alors que l’identité globalesert à identifier l’utilisateur sur la grille.
Ces identités reposent sur des technologies variées (i.e. noms d’utilisateurs Kerberos ou certificats X509) choisies indépendamment par les institutions concernées. XtreemOS a pour objectif de concevoir un mécanisme Single-Sign-On (SSO) qui s’adapte aux différents protocoles d’authentification et qui la sim- plifie tout en préservant la sécurité.
2.2. Principes de conception
Nous exposons dans ce paragraphe les principes de conception du support des organisations virtuelles dans le système XtreemOS.
2http ://shibboleth.internet2.edu/
3http ://www.ietf.org/rfc/rfc3820.txt
4http ://www.oasis-open.org/committees/security/
5http ://www.globus.org
6http ://glite.web.cern.ch/glite/
System-level VO support:
resource usage control, accounting, isolation Security: AuthN, AuthZ, Secure Communication, Single Sign-on, Federation
VO Management (VOM):
identity, attribute, credential, membership, policy
AEM XtreemFS
User Applications
XOS-Cred
VO policies Accounting
info
UID/GIDs, accounting
VO attribute list (e.g.
roles, groups)
Bi-directional ID mapping, XOS-Cred
XOS-Cred XOS-Cred
XtreemOS VO-Centric System Architecture
Offline interaction XtreemOS System component Interaction via XtreemOS system component Online interaction
legend
FIG. 1 – L’architecture de l’administration des VO de XtreemOs
2.2.1. Single-Sign-On
Dans XtreemOS, les droits des utilisateurs sont gérés en combinant l’authentification de niveau Grille avec celle de niveau système. L’accès à l’ensemble des ressources peut être autorisé à partir d’une au- thentification unique. Ainsi, quand un utilisateur se connecte sur une machine XtreemOS, il peut accèder aux ressources de la grille en invoquant des commandes XtreemOS sans avoir conscience de la grille.
2.2.2. Indépendance des utilisateurs et gestion des ressources
Comme les éléments de sécurité sont mis en place au niveau de la VO dans XtreemOS, la gestion des utilisateurs est indépendante de la gestion des ressources. L’ajout (resp la suppression) d’un utilisateur n’a pas d’impact sur la gestions des ressources et l’ajout (resp la suppression ) d’une ressource n’a pas d’impact sur la gestion des utilisateurs. De cette manière, il est possible de gérer indépendamment uti- lisateurs et ressources de plusieurs domaines d’administration. Dans chaque organisation virtuelle, un gestionnaire de VO est responsable de tous les services de gestion. Une autorité de certification (CA) reconnue lui attribue un certificat. Grâce à cela, le gestionnaire de VO peut attribuer des droits aux utilisateurs de la VO qu’il gère pour l’accès aux ressources de la grille.
2.2.3. Transformation des entités de la VO en entités UNIX
Afin de conserver la compatibilité avec les logiciels existants, XtreemOS adopte une approche systé- matique qui consiste à intégrer un support de VO, qui est pratiquement transparent aux services de haut-niveau et aux applications. Ceci implique la mise en oeuvre de mécanismes automatiques qui tra- duisent les identités globales en identités locales et les politiques des VO en droits UNIX. Cette approche permet d’exécuter des applications existantes sur un calculateur XtreemOS tout en tirant bénéfice de l’architecture des VO.
2.2.4. Noyau Linux non modifié
XtreemOS ne modifie pas le noyau Linux pour faciliter l’adoption du système. Cela facilite aussi le suivi de l’évolution du noyau Linux. L’architecture du système XtreemOS est constituée d’un ensemble de services de sécurité s’exécutant au-dessus de Linux ainsi que de quelques mécanismes utilisés pour configurer le système d’exploitation afin de convertir les entités de la VO en entités UNIX.
3. Gestion des VO dans XtreemOS
3.1. Architecture de la gestion des VO dans XtreemOS
Le module de gestion des organisations virtuelles, appelé VOM, est constitué d’un ensemble de ser- vices de gestion de la VO et assure une gestion cohérente des ressources, des droits et des informations dans la VO. Ces cinq services (gestionaire d’identité, gestionnaire des attributs, gestionnaire des certifi- cats, gestionnaire des membres, gestionnaire des politiques) permettent d’authentifier les utilisateurs et d’autoriser ou non l’accès aux ressources.
Les relations entre le module VOM et les autres composants clef incluant le service de gestion des ap- plications (AEM), le service de gestion de données (XtreemFS), le service de support des VO au niveau système et les services de sécurité (resource usage control), sont illustrées par la figure 1. Un certificat XOS-Cred accordé par un service appelé CDA donne des autorisations aux utilisateurs et permet de relier l’ensemble des composants. Il contient une clef privée et une partie publique XOS-Cert compo- sée d’une identité, d’une clef publique et d’attributs. Les attributs peuvent représenter des groupes de personnes qui travaillent ensemble ou des rôles, c’est à dire des responsabilités spécifiques accordées à quelques personnes. Grâce au certificat XOS-Cred, une application peut établir une relation de confiance avec d’autres entités dans la VO, telles que les ressources de calcul et les services de gestion de données.
L’exécution des applications est effectué par l’intermédiaire d’un module nommé gestionnaire des ap- plications (AEM). Ce dernier envoie le certificat XOS-Cert aux ressources de calcul, ce qui leur permet d’authentifier l’utilisateur et de lui d’autoriser ou non l’accès aux ressources. Il détermine aussi, grâce un autre service, les ressources qui ne satisfont pas aux politiques de la VO pour ne pas les utiliser. De plus, le module AEM récupère les statistiques concernant la consommation de ressources afin de réaliser une comptabilité au niveau de la VO en temps réel. Le service de gestion de données XtreemFS [8] est un système de fichier distribué conçu pour le partage des données dans le système XtreemOS. Il permet de contrôler l’accès aux fichiers de données en fonction des attributs des utilisateurs (roles, groupes).
3.2. Services de sécurité pour la gestion d’une VO
Les cinq services de sécurité gérés par un gestionnaire de VO sont décrits ci-dessous.
1. Gestionnaire des membres (X-VOMS). Lorsqu’un utilisateur lance une requête d’un ordinateur vers la grille, le module X-VOMS valide son appartenance en tant que membre de la VO. Un gestionnaire X-VOMS mémorise des informations telles l’identité et les attributs de ce nouvel uti- lisateur.
2. Gestionnaire des identités (IS). Ce module génère et gère les identités des utilisateurs et des VO.
Les nœuds de calcul peuvent vérifier l’authenticité des utilisateurs grâce à leur certificat XOS- Cert. Les nœuds font confiance au VO Manager qu’ils peuvent authentifier par son certificat dont ils possèdent une copie.
3. Gestionnaire des attributs (AS). Il gère les attributs des utilisateurs qui peuvent correspondre à des groupes d’utilisateurs ou aux rôles qu’ils exercent dans la VO. Ils sont utilisés par le module AEM afin de sélectionner les ressources adéquates en fonction des politiques de la VO. Le contrôle d’accès aux ressources et aux fichiers du système XtreemFS s’appuie sur ces différents attributs.
Ces attributs permettent aux nœuds de traduire les identifiants globaux en identifiants UID/GID du système.
4. LeGestionnaire des certificats (CDA). Il fournit aux utilisateurs des certificats de sécurité pour leur garantir l’accès aux services et aux ressources de la grille. Le certificat XOS-Cert utilisé dans XtreemOS est du format X.509. Le CDA a le droit d’accorder un certificat de type XOS-Cred aux utilisateurs car il possède la paire de clés publique/privée du gestionnaire de la VO qui est reconnu par les ressources.
5. Gestionnaire des politiques de la VO (VOPS). Ce module permet à VOM de gérer les politiques de la VO. Le contrôle d’accès aux ressources peut se faire à un niveau supérieur à celui des nœuds (i.e. au niveau VO). L’avantage d’avoir un tel contrôle d’accès est de pouvoir ordonnancer les tâches, négocier les ressources et de contrôler leur usage sur l’ensemble de la VO.
3.3. Support des VO au niveau système d’exploitation
Les systèmes d’exploitation des ressources de calcul appliquent localement les politiques de la VO comme les règles de sécurité, le partage des ressources et les limitations sur l’utilisation des ressources.
Le noyau Linux doit être capable de gérer ces politiques alors qu’il ne connait pas la notion de VO.
Pour le moment, ce sont les outils traditionnels comme les comptes utilisateurs, l’identité des processus et les bits de permission d’accès aux fichiers qui assurent l’isolement et le contrôle d’accès dans Linux.
Bien entendu il ne s’agit pas de modifier le noyau, mais plutôt de fournir aux nœuds un outil qui trans- forme les identités et les politiques de la VO en identités et droits d’accès reconnus par Linux. Pour ce faire, XtreemOS utilise des mécanismes existants afin de faciliter la mise en application des politiques et l’isolement des VO.
3.3.1. Gestion des VO, traduction des identités globales des utilisateurs de la Grille en identités locales
Dans XtreemOS, il est nécessaire que les mécanismes utilisés pour traduire l’identité des utilisateurs de la grille en entité locales soit flexibles, sécurisés tout en passant bien à l’échelle. Plusieurs modules déjà présents dans le système d’exploitation Linux le permettent. Il s’agit du module d’authentification PAM, du moduleName Service Switch (NSS)et du moduleKernel Key Retention Service (KKRS). Leurs fonction- nalités seront détaillées plus tard dans l’article. PAM et NSSwitch peuvent être installés et configurés par des administrateurs système sans changer le noyau. On peut traduire les requêtes des utilisateurs prove- nant des VO de plusieurs manières, en choississant les modules PAM/NSSwitch adéquats. Dans Xtree- mOS, il est possible de donner aux utilisateurs un compte anonyme comme cela est fait dans Globus, ou alors un compte déjà existant pour ce genre d’opération comme dans GUMS [2] et LCAS/LCMAPS [1].
Cependant, la gestion des VO à plus grande échelle dans XtreemOS est rendue possible en générant dynamiquement des comptes locaux sur les ressources de calcul, à partir des certificats XOS-Cert des utilisateurs. Plusieurs comptes peuvent être actifs simultanément mais leur nombre ne dépasse jamais le nombre d’utilisateurs partageant effectivement la ressource à un instant donné.
3.3.2. Interface avec les services d’authentification de la grille
Le modulePluggable Authentication Modules (PAMs) [6] rassemble des technologies d’authentification (Kerberos, mots de passe UNIX, RSA) sous une unique API de haut niveau. Les applications qui néces- sitent une authentification peuvent être développées sans se soucier du mécanisme d’authentification sous-jacent. Comme le module PAM est très répandu dans les distributions Linux, XtreemOS peut l’ex- ploiter afin d’assurer la compatibilité entre Linux et les services d’authentification de la grille. Lors de la phase d’authenfication, les utilisateurs de la grille sont authentifiés à l’aide de leur certificat XOS-Cred par un module XtreemOS-PAM développé spécifiquement pour XtreemOS. C’est dans la phase d’auto- risation que les politiques de la VO sont mises en application. Enfin la phase d’administration de session permet de gérer tout ce qui est création et destruction de comptes locaux, nettoyage des fichiers et des processus, certificats de sécurité et mises à jour des traductions des identités de la grille en identités locales au format UID/GID.
3.3.3. Traduction des droits d’accès des utilisateurs
Lorsqu’un utilisateur effectue une requête vers une base d’utilisateurs ou de groupes UNIX, le mé- canismeName Service Switch (NSS)[4] l’intercepte. Celle-ci n’est pas dirigée vers les bases de données UNIX mais plutôt vers d’autres comme NIS+, LDAP, etc qui permettent une gestion globale des comptes utilisateur pour un réseau de machines. Dans notre cas, c’est vers une base accessible grâce à un service nomméAccount Mapping Service (AMS)que la requête est redirigée. Les informations stockées corres- pondent aux comptes locaux gérés par XtreemOS-PAM.
3.3.4. Contrôle d’Accès et Enregistrement
LeKernel Key Retention Service (KKRS)[5] stocke les données d’authentification d’un processus dans le noyau. Ces informations peuvent être exploitées par d’autres services du système comme les systèmes de fichiers pour gérer le contrôle d’accès. Elles sont aussi utilisées pour authentifier des applications en espace utilisateur.
Lorsqu’un utilisateur se connecte pour la première fois, le module PAM stocke le certificat de l’utilisateur XOS-Cred dans le KKRS afin qu’il soit dynamiquement associé à tous les processus initiés suite à sa
requête. Le KKRS est consulté à chaque fois que le certificat XOS-Cert de l’utilisateur est nécessaire.
Par exemple, plusieurs services comme XtreemFS peuvent vérifier les autorisations d’un utilisateur rien qu’en consultant son certificat. De plus, pour garder trace de l’utilisation des ressources, le noyau a besoin du XOS-Cred de l’utilisateur. Ces enregistrements comportant l’identité globale des utilisateurs doivent être fournis au propriétaire de la ressource et au gestionnaire de la VO. La relation entre les droits utilisateurs de niveau grille et les UID/GIDs du niveau nœud sont gérés par XtreemOS-PAM.
3.3.5. Isolement dans XtreemOS
XtreemOS prend en compte plusieurs formes d’isolement pour protéger l’identité des utilisateurs, les fichiers et les processus. On retrouve plusieurs types d’isolement comme celui des attributs, des objets, des interfaces des services et des processus. Lorsque plusieurs utilisateurs partagent la même ressource, il faut s’assurer que l’activité d’un utilisateur ne perturbera pas les autres. Si la réservation d’une res- source devait échouer pour un client, cela ne doit pas rendre indisponible les réservations faites par d’autres clients. De plus, les traces, les données de sortie et la vision qu’a un client sur une ressource ne doivent pas être sensibles aux interactions entre cette ressource partagée et d’autres clients.
3.3.6. Composants et protocoles d’isolement
L’isolement d’une ressource partagée est déterminé par les VO qui l’utilisent. On peut représenter loca- lement une VO par un conteneur appeléXOS-Containercontenant un ensemble de sujets et de ressources isolés pour chaque VO. Il existe plusieurs mécanismes de communication ou de gestion de conteneurs tels leur création, l’accès au système d’exploitation, l’ajout ou la suppression de ressources, la gestion de requêtes entrantes vers celles-ci ou des requêtes sortantes vers les sujets. Ces protocoles font appel à diverses communications sécurisées afin d’interagir entre-eux.
4. Mise en œuvre
Nous décrivons maintenant un premier prototype qui a été réalisé dans le cadre du projet XtreemOS [7].
4.1. Prototype de niveau système
Une fois qu’un utilisateur est authentifié à l’aide des certificats X.509, un compte lui est associé sur la machine fournissant la ressource. Cette gestion dynamique des comptes est rendue possible grâce à un prototype utilisant les modules XtreemOS-PAM et NSSwitch. Ce prototype contient également une implémentation améliorée de SSH (Secure Shell) qui étend les capacités d’authentification (SSH) de l’utilisateur à son certificat XOS-Cert. Les informations concernant les traductions utilisateurs de la grille/comptes UNIX locaux sont stockées dans une base de données indépendante.
Ce prototype est illustré par la Figure2. Un utilisateur de la grille obtient un certificat XOS-Cert que lui fournit le gestionnaire de la VO. Le certificat est associé à l’application utilisateur qui accède à un nœud fournissant des ressources. PAM vérifie la validité du certificat XOS-Cert et le stocke dans le KKRS en l’associant avec le processus utilisateur. De ce fait, le certificat peut être fournit par le processus et ses fils aux différents services locaux et distants à des fins d’authentification.
Lorsqu’un processus veut accéder à une information concernant un utilisateur ou un groupe, on doit savoir à qui il appartient. Pour ce faire, on fait appel au module KKRS qui retrouve les certificats du processus. Ceux-ci sont retournées au module NSSwitch puis au module AMS. Ce dernier décide en fonction des droits du processus si l’information peut être fournie.
4.2. Implémentation au niveau de la grille
Seuls le VOPS et le CDA offrent des interfaces externes aux autres services de XtreemOS comme l’AEM.
La Figure3 montre comment se déroulent la gestion des ressources et la soumission des tâches. Lors- qu’un utilisateur lance une application depuis sa station de travail afin d’utiliser les ressources de la grille, le CDA lui fournit un certificat XOS-Cred. Ensuite l’application de l’utilisateur soumet une re- quête au service de recherche de ressources de l’AEM. Celui-ci vérifie le XOS-Cred de l’utilisateur et trouve des ressources adéquates pour la requête. Le VOPS trouve des ressources dont les politiques cor- respondent à la requête de l’utilisateur et lui en retourne une liste. L’utilisateur peut donc accéder aux nœuds en leur présentant son certificat XOS-Cred et leur demander des ressources pour exécuter ses tâches.
FIG. 2 – Implémentation de niveau système : authentification et traduction de compte
Afin d’implémenter le service CDA, le système MyProxy7est utilisé grâce à sa capacité de distribuer des certificats et grâce aux divers choix d’authentification qu’il offre (i.e. Kerberos, GSI).
XACML8 est utilisé dans l’implémentation de VOPS car son standard XML lui permet de définir de nombreuses politiques d’accès.
5. Conclusion
Le support fourni par XtreemOS permet de gérer les ressources au sein d’une organisation virtuelle.
L’objectif est d’accepter un grand nombre d’utilisateurs et de ressources tout en évitant d’altérer l’ef- ficacité du système d’exploitation. Linux a été modifié de manière minimale afin d’implémenter les différents services de la grille pour que notre outil s’adapte à différentes plateformes et soit compatible avec les applications existantes. On retrouve ci-dessous plusieurs avantages de XtreemOS par rapport aux approches mises en oeuvre par Globus ou Glite.
Les objets du système et les applications n’ayant pas conscience de la grille peuvent être utilisés sans être modifiés ou recompilés car les modifications apportées à l’OS sont transparentes. La traduction des identités globales des utilisateurs de la grille vers les comptes utilisateurs locaux d’une machine se fait de manière dynamique et les informations nécessaires ne sont pas stockées dans une base de donnée centralisée mais dans le système.
Les utilisateurs locaux ne peuvent pas savoir quel utilisateur de la grille utilise quel compte car les tra- ductions ne sont pas stockées dans les fichiers du système. La gestion des utilisateurs est indépendante de celle des ressources, ce qui facilite l’ajout et la suppression des ressources et des utilisateurs impli- qués dans les organisations virtuelles. Le passage à l’échelle est donc simplifié car l’ajout éventuel d’un utilisateur dans la VO ne force pas les ressources à modifier leurs données pour référencer ce dernier.
7http ://myproxy.ncsa.uiuc.edu/
8http ://www.oasis-open.org/committees/xacml/
XOS - Security services involved in job submission process
8. Negotiate resources and submit job to resource node 1. XSub
5. Check VO policies with XOS-Cred 6. Policy decisions
Rough correspondence to D3.5.3:
1, 2, 3: Section 5.6.1 - AEM Job creation 4, 5, 6, 7: Section 5.6.2 - AEM resource matching 8: Section 5.6.3 - AEM resource negotiation
WPs involvement:
1: WP3.3 2, 3: WPs 3.3 + 3.5 4, 7: WPs 3.3 5, 6: WPs 3.3 + 3.5 8: WPs 3.3 + 3.5 + 2.1
CDA VOPS
VO Management
AEM Job Management Service
AEM Resource Matching Service
2. Cert request
3. XOS-Cred 7. Authorized
resources 4. Find
resources with XOS-Cred
Linux Terminal
Resource Node User Application
FIG. 3 – Implémentation de niveau grille : support exécutif de l’application
6. Travaux futurs
De nouvelles fonctionnalités seront bientôt implémentées afin d’étendre le support des VO dans Xtree- mOS. Un utilisateur peut partager les données de manière sécurisée entre plusieurs VO. De plus, il sera possible de supporter tout le cycle de vie d’une VO, de l’initialisation à la terminaison et aussi de créer des VO dynamiques pour la durée d’une application. Enfin, les évolutions Linux telles que les conteneurs et les machines virtuelles (KVM) seront prises en compte au fil du temps.
7. Remerciements
Nous remercions les autres membres de l’équipe XtreemOS (Brian Matthews, Luis Pablo Prieto, Erica Y.
Yang et Haiyan Yu) qui ont contribué à la rédaction de cet article ainsi que le support de la commission européenne dans son programme #FP6-033576.
Bibliographie
1. Alfieri (R.) et al. – Managing dynamic user communities in a grid of autonomous resources.In : Proc. Computing in High Energy and Nuclear Physics. – San Diego, California, USA, mars 2003.
2. Baker (R.), Yu (D.) et Wlodek (T.). – A Model for Grid User Management. – Rapport technique, 2003.
http://www.citebase.org/abstract?id=oai:arXiv.org:cs/0306063.
3. Coppola (Massimo), Jégou (Yvon), Matthews (Brian), Morin (Christine), Prieto (Luis Pablo), Sán- chez (Oscar David), Yang (Erica Y.) et Yu (Haiyan). – Virtual Organisation Support within a Grid-wide Operating System, November 2007. Submitted for publication.
4. Free Software Foundation, Inc. – GNU C Library Reference Manual. – Rapport technique.http:
//www.gnu.org/software/libc/manual/.
5. Kumar (A.) et Chopdekar (S.). – Get started with the Linux key retention service. – Rapport technique, avril 2007. http://www.ibm.com/developerworks/linux/library/l-key-retention.
html.
6. Samar (V.) et III (R. J. Schemers). – Unified Login with Pluggable Authentication Modules (PAM). – Rapport technique, octobre 1995.
7. The XtreemOS Team - Work Package 2.1. – Prototype of the basic version of Linux-XOS (Xtree- mOS Deliverable D2.1.4). – Rapport technique, November 2007. http://www.xtreemos.org/
publications/public-deliverables.
8. The XtreemOS Team - Work Package 3.4. – The XtreemOS File System - Requirements and Re- ference Architecture (XtreemOS Deliverable D3.4.1). – Rapport technique, December 2006. http:
//www.xtreemos.org/publications/public-deliverables.
9. The XtreemOS Team - Work Package 4.2. – Requirements Capture and Use Case Scenarios (Xtree- mOS Deliverable D4.2.1). – Rapport technique, January 2007. http://www.xtreemos.org/
publications/public-deliverables.
