1 / 16

Welcome to the Gateway Security Summit

Welcome to the Gateway Security Summit. Nancy Wilkins-Diehr Science Gateways Area Director. Goals for the next two days. The goal is to carefully define How gateways will use community accounts Shell access for developers? Job execution capabilities for users

sugar
Download Presentation

Welcome to the Gateway Security Summit

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Welcome to the Gateway Security Summit Nancy Wilkins-Diehr Science Gateways Area Director Gateway Security Summit, January 28-30, 2008

  2. Goals for the next two days • The goal is to carefully define • How gateways will use community accounts • Shell access for developers? • Job execution capabilities for users • How sites will secure these accounts • Will developers need to make help desk requests for any writes to community account directory? • How the community account request process will function • The goal is not to have all sites to agree on how accounts will be secured • But we do need to define how all sites will secure these accounts and advertise this to users • And we want to try not to have 11 different approaches • Many examples of the process breaking today Gateway Security Summit, January 28-30, 2008

  3. How did we get to where we are today? • October, 2005 • NSF Resource Allocations Policy updated to include support for community accounts through the allocations process • Phil Andrews, Ralph Roskies, John Towns, Nancy Wilkins-Diehr edited policy to react to user feedback on a variety of issues • Community Services: Proposals of this type are intended to support projects that provide services to a large community of users who are typically not collaborating with the PI of the submitted proposal. An example of such a project would be an application portal service providing access to software and cycles to a community of users via the developed service. • This type of proposal needs to describe the services provided, the methods used and the expected consumption of resources. It is anticipated that most such services will consume resources under a single or very limited number of logins, but that the service itself will provide some tracking of usage by individuals making use of the service, and this should be reported in renewal requests for resources, progress reports, and end-of-project reports. • Originally written to support CASP protein structure prediction community Gateway Security Summit, January 28-30, 2008

  4. Community Account Policy History • September 2006, Community account policy approved by RPF • Community accounts will be set up by TeraGrid resource providers (RPs) and secured according to local policies. • Accounts will be identified in the TGCDB by “Community User” in the last name field • Gateways are responsible for ensuring secure use of this login and refers to the user responsibility form, which had been specifically expanded and agreed upon to cover community account responsibilities. • End gateway users many not upload arbitrary executables through the community account. • TeraGrid will provide an optional service which sends problem jobids from an RP site to Gateway administrators in the event of an incident, allowing developers to disable access for the problem user and allowing the community account to remain active Gateway Security Summit, January 28-30, 2008

  5. January, 2007, Policy approved by security-wg • February, 2007, Policy sent to wg@teragrid.org for comments, there were two to address • “Only the community credential should be mapped (via the grid-mapfile) to the community account to prevent delegated credentials from other mapped credentials being made available to community users.” (Von Welch) • Implementation, not added to policy doc • “Community Software Area should not be writable by any associated community account. As this would allow a compromised portal to (over-)write applications which it could then execute.” (JP Navarro) • Done in CSA policy doc, loop closed with those installing CSAs Gateway Security Summit, January 28-30, 2008

  6. More History • May, 2007 • Community accounts are a topic on an RPF call, further clarity requested on • Specific responsibilities of the RP's, PI's, and GIG • Documented procedure for checking that the PI's logging responsibilities have been carried out • Possibly a pointer in the policy document to an implementation procedures and common practices, etc doc, so that RP's are generally doing the same thing. • Both PSC and TACC for example are suggesting that they are implementing something such that a message like "No services have been defined for this account, contact Joe Smith at 123-4567" until they have spoken directly with the PI and got the implementation of the community account details worked out. • Policy addresses identification of community accounts in TGCDB and some usage restrictions • Does not address RP implementation • States that the policy will evolve as further requirements are identified by security-wg, thus leading us to where we are today! Gateway Security Summit, January 28-30, 2008

  7. Why a Face to Face Meeting? • Considerable work on the issue in both security-wg and gateways • Thank you all for your contributions • Current process not working for end users • Usage models and implementation strategies require further definition • Face to face meeting needed come to resolution on several important topics • Critical Issues • Carefully define usage models • Carefully assess risk • Thoughtfully restrict accounts on par with risks • Do not want a major gateway security incident involving TeraGrid • Severe restrictions may have a significant impact on the gateway program • Gateways reduce the impact of thousands of end user laptops, but may increase other risks • Gateways are a very important capability for both TeraGrid and the NSF • We want them operated securely Gateway Security Summit, January 28-30, 2008

  8. TeraGrid is a service organization • Must occasionally step back and look at the big picture • What are our processes like for the end user? • TeraGrid is a tool users use to accomplish other goals • They have to worry about funding the science work, teaching class, writing papers, etc. • They don’t have time to become familiar with all the intricacies of our processes, but they do their best to understand what they need to know • If TeraGrid is too frustrating to use, users will push harder for their own machines • NSF would like to see TG take the place of some individual hardware awards on grants because it is more cost effective • We need to make sure they have a good experience Gateway Security Summit, January 28-30, 2008

  9. How do Gateway PIs begin using TeraGrid? • Write allocation proposal • POPS login • Follow our detailed instructions, can only submit larger requests during very specific windows • Justifications, paper listings, renewals each year • Supplements and extensions • PI must use add user form to add each and every developer • Go through this process again if a new platform of interest is added • If the PI wants a community account • Submit form providing a contact info (again), short and long description of gateway, gateway URL • Gateway is then listed on the public page • Get user portal login, login to portal, go to MyTeraGrid and then community account form • Provide contact info (again), script locations, anticipated run sizes, anticipated data needs, IP address • Wait for community account setup at sites • Go through this process again if a new platform of interest is added Gateway Security Summit, January 28-30, 2008

  10. Accounts are set up, on to software • If the PI wants to stage software somewhere other than a home directory • Request community software area (CSA) • First name, last name, disk required, for how long, directory name, group members, email for each group member, requested sites • Need to make sure community account group membership does not intersect with CSA group membership • Don’t want community account to have write access to visible software areas like CSAs • Go through this process again if a new site of interest is added • Now the PI has • An allocation • Developer accounts • A community account • A software area • Time to run some jobs Gateway Security Summit, January 28-30, 2008

  11. Let the programming begin • Developers add TG calls into their own fully developed gateway • Queues • GRAM job submissions • Input file verification • Gridftp • Identify striped and non-striped servers • Accounting • GRAM audit • Report to us quarterly on number of end users using gateways • Attributed-based authentication • Credential management • Upload logs that include gateway use of TG • Discussion over the next two days about exactly how developers should use the combination of individual and community accounts for gateway development • We need to make sure the TeraGrid experience is worth this level of effort! Gateway Security Summit, January 28-30, 2008

  12. Easy as 1-2-3! Fully diagrammed login and certificate set-up process, pre-Single Sign-on You can see from the flow chart that things could potentially be easy.  The most important thing I get from this in hindsight is that it was all exception driven. Gateway Security Summit, January 28-30, 2008

  13. We are asking a lot of our users • We need the processes to at least work as advertised or change the advertising • Proposal process • User and community account requests • Community software area requests • Auditing • Attribute-based authentication • Focus on community accounts at this meeting Gateway Security Summit, January 28-30, 2008

  14. Recent Community Account ExperienceNational Biomedical Computation Resource Sent: Wednesday, October 31, 2007 5:57 PMI did some login and GSI authentication test for the "nbcruser" on Teragrid. Some sites don't work, can you help me to figure this out?    First, I can get the proxy from myproxy.teragrid.org.    SDSC: Everything works.    NCSA: At the early of this month, I could login NCSA clusters from laptop and NBCR machines, and GSI authentication was also successfully. For now, I can not login NCSA with the passwd, authentication also failed, but I still can login NCSA from SDSC teragrid machine, and the authentication from SDSC to NCSA is successful.     PSC: Login and authentication never work.    Purdur Univ: The passwd of "nbcruser" isn't provided on the paper, and GSI authentication failed.    TACC: I can login to the cluster, but the provided username is "tg459196", not the uniform "nbcruser" Gateway Security Summit, January 28-30, 2008

  15. This summit will improve that user’s experience Gateway Security Summit, January 28-30, 2008

  16. Goals for the next two days • The goal is to carefully define • How gateways will use community accounts • Shell access for developers? • Job execution capabilities for users • How sites will secure these accounts • Will developers need to make help desk requests for any writes to community account directory? • How the community account request process will function • The goal is not to have all sites to agree on how accounts will be secured • But we do need to define how all sites will secure these accounts and advertise this to users • And we want to try not to have 11 different approaches • Many examples of the process breaking today Gateway Security Summit, January 28-30, 2008

More Related