1 / 13

Grid Security Overview

Grid Security Overview. presented by Von Welch National Center for Supercomputing Applications. A New VO: Day 0. People and resources spread around the campus, state, country or globe Each resource local site rules under which they have to play

rpolly
Download Presentation

Grid Security Overview

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. Grid Security Overview presented byVon WelchNational Center for Supercomputing Applications

  2. A New VO: Day 0 • People and resources spread around the campus, state, country or globe • Each resource local site rules under which they have to play • Resources may have deployed authentication mechanisms (Kerberos, AFS) that aren’t going away • No common database of users, passwords across VO

  3. VO Security Goal • Main challenge of VO security is setting up trust among this group of previously unconnected resource providers • Resource providers must establish trust of: • The technology • The users - authentication, behavior • Each other - incident response, logging, practices, communication, etc. • The the VO - authorization being appropriately given

  4. Steps to Establishing Trust • Identify the right people • Need to be able to speak authoritatively on security policies for resources • Might need to be site authorities for stringent sites or sites with large number of resources involved • Involve them as early as possible • Foster understanding of technologies through documentation, discussion • Identify security requirements of users, sites, other stakeholders • Decide policies on authentication, authorization, logging, etc • Site AAA Research Group in GGF has documents capturing a example set of requirements

  5. Authentication Policy • Globus provides basic authentication mechanism • GSI based on X.509 certificates • Pick a certificate authority (CA) • Choose an existing CA(s) • Find those that conform to requirements • And can server user community • Roll their own • Registration authority (RA) structure to cover all users • Draft policies for operation (certificate policy) • Documentation for users

  6. Authorization Policy • Who get what access? • Globus provides simple ACL-based method (grid-mapfile) • Policy will change over time, as users and resources come and go • Who decides? • How is information distributed to resources?

  7. Security Tools • Certificate Management • Getting users “signed up” to use the Grid • Getting the user’s Grid credentials to wherever they’re needed in the system • Authorization/Access Control • Tools for storing and providing access to system-wide authorization information • Central data store for supporting decentralized control mechanisms

  8. Kerberos Integration • Institutions that already have a Kerberos realm can use KX.509 and KCA to provide local users with Grid proxy certificates without using a Certificate Authority. • When users authenticate with Kerberos, they may obtain proxy certificates in addition to their Kerberos tickets. • KCA is a Kerberized certification service, and KX.509 is a Kerberized client that generates and stores proxy certificates. • Unlike MyProxy, KX.509 and KCA create credentials for users, so remote sites must be configured to trust the local KCA service’s certification authority. • PKINIT is a service that allows users to use Grid certificates to authenticate to a Kerberos realm.

  9. User Registration Service • Portal extensions (CGI scripts) that automate user registration requests. • Solicits basic data from user. • Generates cert request from ESG CA (implemented with “simple CA” from GT). • Admin interface allows CA admin to accept/reject request. • Generates a certificate and stores in MyProxy service. • Gives user ID/password for MyProxy. • Benefits • Users never have to deal with certificates. • Portal can get user cert from MyProxy when needed. • Database is populated with user data. • Orginally written for ESG, being generalized for reuse in other projects!

  10. Community Authorization Service (CAS) • GT component to allow fine-grain file control access • Central DB stores information on users, groups, files and rights • Cas-proxy-init • Uses existing proxy to contact CAS server and get CAS credential listing user rights • Administrative tools for managing DB • Hooks in GT 3.2 GridFTPd to enforce rights

  11. VOMS • Similarto GT CAS • Database of user roles and capabilities • Administrative tools • Client interface • voms-proxy-init • Uses client interface to produce an attribute certificate (instead of proxy) that includes roles & capabilities signed by VOMS server • Works with non-VOMS services, but gives more info to VOMS-aware services • Allows VOs to centrally manage user roles and capabilities for GRAM access

  12. EDG-mkgridmap • Builds grid-mapfiles from LDAP directory or VOMS server • Allows central storage and distribution of user database • Scripts are run to automatically contact central DB and build local grid-mapfile

  13. VOX and VOMRS Extends VOMS to include an ESG-like registration service • Web registration interface • Builds user database with extended fields • Populates VOMS server

More Related