> On Aug 12, 2016, at 3:32 PM, Jarett DeAngelis <[email protected]> wrote: > > And to expand on this a little — what do you think the development effort > would look like for the job submission on the compute nodes to run as the > users rather than as Airavata’s service account, if we were to take it > farther?
The development task is small but operational implications are huge. To elaborate, gateway administrators manage the service accounts and they can debug when jobs fail. Most of these system failures are with application environments (having right dependencies and so forth). Once the jobs are submitted from user accounts, these lead a debugging nightmares exchanging lot of emails reproducing and fixing. Essentially forcing users getting familiarize to use HPC. For most of the current users who are transitioning to using gateways this should not be an issue. But as new users are encouraged to use HPC without necessarily understanding the nuts and bolts, some one else has to absorb the details. Suresh > > Thanks again, > Jarett > >> On Aug 12, 2016, at 3:23 PM, Jarett DeAngelis <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hey Suresh, >> >> Thanks for starting this conversation! >> >> What do you think the users’ “extra one time configuration” would look like? >> >> One of the things I was thinking about was how the gateway can do things >> like pass a path to the compute node in order to find files. Is it possible >> for the gateway to produce a “file picker” sort of dialog based on what it >> can see in a path you give it? It runs jobs as its service account when >> Airavata interacts with it. You might not have to have it run *as* the user >> in order to produce a directory listing for acquiring and depositing files, >> if the user changes the permissions on a certain set of directories such >> that the service account can read/write to them. >> >> Does this make sense? Would it be a large development effort to get this >> additional bit of UI functionality? Obviously part of the purpose of a >> science gateway is to avoid having to dig around on the command line sorting >> out what files are where. >> >> Thanks! >> Jarett >> >>> On Aug 8, 2016, at 2:17 PM, Suresh Marru <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Jarett, >>> >>> To give some context, let me start refreshing the security(authentication >>> and authorization aspects) within Airavata. >>> >>> There are clearly two distinct layers, users securely interacting with >>> Airavata and Airavata able to security interact with storage and compute >>> resources. The former interactions are facilitated with WSO2 IS and later >>> managed by Airavata Credential Store. For your use case we need to >>> brainstorm on how we bridge the two. You can read more about Credential >>> Store here [1]. >>> >>> If I am understanding your scenario, users authenticate on PGA with the >>> credentials in LDAP/FreeIPA (brokered through WSO2 IS). Airavata then >>> allows them to use compute resources managed by roles in the IS (in the >>> future we might replace this with more fine grained group management). All >>> authenticated and authorized users can interact with storage and compute >>> resources which the gateway administers have enabled them by retrieving the >>> credentials stored in the credential store. Currently only administrators >>> generate and configure these credentials. We have considered power users >>> (with appropriate role privileges also using credential store directly). >>> >>> If your use case is for every user, then we need to essentially have them >>> delegate access to their personal storage space. Access protocol is not not >>> too much of an issue to support, how seamlessly and security we can have >>> users delegate their storage credentials is a challenge. Its not a major >>> development effort, but its more of a usability issue. If we need to do it >>> in a good secure way, users should be prepared to do extra one time >>> configuration. If we need to have users do nothing, then that will lead to >>> less secure options. >>> >>> Can we outline from a usability standout what will be a acceptable >>> credential delegation (access to their storage space) and build from there? >>> >>> Cheers, >>> Suresh >>> >>> [1] - >>> https://scholarworks.iu.edu/dspace/bitstream/handle/2022/17379/ccgrid_2014_credential_store.pdf >>> >>> <https://scholarworks.iu.edu/dspace/bitstream/handle/2022/17379/ccgrid_2014_credential_store.pdf> >>> >>> >>>> On Aug 2, 2016, at 5:08 PM, Jarett DeAngelis <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi all, >>>> >>>> When the PGA gateway is dealing with something like getting files to and >>>> from user space (like an NFS share, for example), what is the canonical >>>> way of doing this? Since the gateway is running as the Apache service >>>> account, it does not have permissions on the user's directories. Is there >>>> something standard you can put into an application interface to let it get >>>> files back and forth? Like, some kind of spot for ssh/scp URIs, for >>>> example? I dunno, putting scp://user:password@host:~/path/to/directory >>>> <scp://user:password@host:~/path/to/directory> in for a path? Or some more >>>> nicely-designed file picker-type interface that uses the PGA user’s logged >>>> in credentials (in our case, from LDAP/FreeIPA)? >>>> >>>> Thanks in advance, >>>> Jarett >>> >> >
