Grid Security Infrastructure and Global Access to Secondary Storage

1
Grid Security Infrastructure and Global Access to
Secondary Storage

• Announcements/Review
• HW2, Due Saturday, 2/6
• Last Time
• Nexus Communication infrastructure
• basic abstractions
• mapping onto systems
• encryption and other layering in Nexus
• Globus Security Infrastructure
• basic challenges for a Grid security
  infrastructure

2
Todays Outline

• Grid Security Architecture Issues
• What are the unique challenges for Grid Security
• A Framework for Grid Security
• Perspective
• Global Access to Secondary Storage
• Motivation and Requirements
• Grid Applications and Distributed Filesystems
• Gass operations and performance

3
Grid Security Infrastructure

• GSI -- how to provide secure remote access to
  resources you dont own?
• Typical models
• Remote user login requires Authentication and
  existing accounts relationships
• Clients authenticated to servers (and in some
  cases vice-versa)
• two-party authentication much of the focus
• Shared resources require Autonomy in management
  of security at each site, all authentication must
  be done with local credentials
• What can a shared infrastructure do?

4
Grid Security

• Site Autonomy -- base authentication and access
  privileges are not up to the grid system
• Grid systems provide convenience,
  rationalization, and unification for Grid users
• Smooth over the complexity of the environment for
  a user.
• Maintain credential mappings and initiate on
  users behalf (trust Globus?). Integrated with
  job initiation and resource accounting.
• Support multiprocess, many party mutual
  authentication kinds of issues.

5
Grid Execution Model

• User initiates a job, it goes to multiple
  systems,
• Processes create other processes, large numbers
  of communications, within and across trust
  domains
• Two level (at least) credential and security
  model
• All sites must buy-in (to enable the grid
  security model), and users must obtain access
  both globally and locally

6
Global and Local Subjects
Global achien

• Global user identity
• Grid infrastructure provides association of
  global and local identity (trust)
• Local identity must be delegatable (doesnt
  require online user involvement)
• possible loss of control, required for large
  scale use?

7
Group Authentication
?

• Group identity and shared credentials
• Not unique for each member, group identity,
  parallel spawn
• Cross trust domain mutual authentication
• Cross mapping of identities for direct access
  (correspondence, for example for I/O)

8
A Grid Security Policy

• Defines the basic constraints and design
  objectives
• Separates the questions -- what is acceptable
  security? What is an appropriate implementation
  of that acceptable security policy
• 8 key policy elements follow

9
Grid Security Policy (Cont)
GSI

• (1) Multiple Trust Domains
• Grid policy must integrates the local policies
• Defines the interactions of the domains
• Mapping of grid security policy into local
  policies
• Mapping of local requests into Grid policy and
  capabilities

10
Grid Security Policy (cont II)

• (2 and 6) Autonomy
• Operations confined to a local trust domain are
  subject to local security policy ONLY
• Non-interference, non-intrusion, non-compromising
• Local Access control decisions made on the basis
  of local subject
• (3 and 5) Global Subjects
• Both global identity and local identities exist
• There is a relationship between them otherwise
  global is irrelevant
• Authenticated Global subject mapped into a local
  subject is assumed to be equivalent to being
  authenticated as that local subject
• Global to local mapping is trusted by the local
  security policies

11
Grid Security Policy (cont III)

• (4) Mutual Authentication
• Operations between entities located in different
  trust domains requires mutual authentication.
• Each must be authenticated to the other
• This can only happen through a mapping (or
  service) which relates the two domains (e.g. a
  Grid Security Infrastructure)
• This may need to be scalable as there may be
  pairwise connections between 100s or thousands
  of pairs.
• (7) Delegation
• A program or process is allowed to act on behalf
  of a user and be delegated a subset of the users
  rights.
• User cant do everything directly (scalablity)
• User may not wish to be involved in the details
• This allows transient credentials to be used
  (safer)

12
Grid Security Policy (cont IV)

• (8) Credential Sharing
• Processing running on behalf of the same subject
  within the same trust domain may share a single
  set of credentials
• de facto definition of a group for security
  purposes
• avoids need for generation and maintenance of
  thousands of sets of transient credentials (and
  resulting tracking and management overhead)

13
Discussion

• Is this a reasonable policy?
• What constraints does this policy imply?
  Assurance? Architecture? Audit? Administration?
• What other policies might be reasonable?
• What assumptions are critical and which are
  ancillary?

14
An Implementation of the GSP
User
User Proxy
RP
RP

• User proxies are transient with transient
  existence and credentials (established
  association enables proxy capability)
• Resource proxies translate between interdomain
  and local intradomain mechanisms
• Mapping tables are maintained by the resource
  proxies, under control of the local sites

15
Typical Access Mode

• User creates a user proxy
• where? Maybe anywhere w/ global identity
• User proxies interact with resource proxies to
  allocate resources within their respective trust
  domains
• by contacting the local resource proxies
• success or failure (allocation, authentication,
  authorization)
• Job is running in multiple sites.

16
Questions

• How to achieve mutual authentication in this type
  of framework?
• Each resource proxy only maintains its
  global/local mappings
• Resource proxies must validate for each
  connections?
• Another level of proxying?
• Something else?
• How does credential sharing fit into this picture?

17
Discussion

• Does it meet the requirements?
• How does it meet the requirements? Is it
  manageable, trustable?
• What are the key new problems that it solves?
• Do the solutions seem realistic for 100s of
  nodes?
• 1000s? Millions? Billions?
• How about thousands of users? Millions?
  Billions?
• What types of devices might be appropriate?
• How does this relate to current security
  architectures? Kerberos? NT domain?

18
Global Access to Secondary Storage

• Move the computation and sensors around
• How to connect it to the data?
• Naming
• Global uniform filesystem, Federated namespace
• Data Management
• Movement, Caching, Semantics

19
Requirements for Grid Storage

• Uniform naming
• User cant use a special name doesnt know where
  the computation is executing
• Would like uniform naming and source selection
  (transparent data management)
• Efficient Data Movement
• Supercomputing applications require high volume
  I/O
• Data intensive applications require high volume
  I/O
• Sensor and data digestion applications require
  real-time streaming I/O
• Programmer-controlled I/O Optimizations
• Enable programmer optimization (special knowledge)

20
Requirements for Grid Storage (cont)

• Dynamic Resource Access
• cant require all things to be crossmounted
• Convenience Support for streaming I/O
• enable piping
• distributed program composition
• Grid shell programming

21
GASS A Simple Solution
Protocol//ipname/filepath

• Uniform namespace
• URLs protocol//hostname/fname
• binds the file to a particular location?
• not according to the IETF
• federates filesystems and allows local control of
  sections of the namespace
• allows specification of an access protocol

22
GASS API

• I/O Operations
• globus_gass_open(), globus_gass_fopen(),
  globus_gass_close(),globus_gass_fclose()
• File Caching
• explicit control if desired
• cache data
• control naming for transparency (local fsystem,
  rename cache)
• reference counting for reclamation
• tagged reference counting for recovery
• globus-rcp (explicit prefetching)

23
Typical file access patterns

• Read-only sharing
• Append-only access
• Unrestricted Read/Write with exclusive access
• Files with multiple writers, written by several
  processes in turn (and no data shared) -- entire
  replacement

24
GASS Data Movement Optimizations

• Caching
• exploit local disk
• decouple access latency from application
  execution
• what to do about large files?
• Streaming without local caching for append files
• When to cache?

25
Optimizing the Common Cases

• Executable and initial data set input
• constant, common data
• constant, disjoint data
• gt prefetch and cache on first read
• Simulation or Processed Data Output (whole file)
• write an entire file of new data
• replaces other files completely, or is a new file
• gt flush and transfer on last write close

26
Common Cases (cont.)

• Append to a log file or simulation trace file
• Open a network connection
• Move data as it is written to the remote system
  and write it (extend Unix buffered I/O model over
  the network)
• Are these all of the common cases?
• For sequential I/O?
• For parallel I/O?

27
Common Cases (cont. II)

• Sequential I/O
• cooperative appending (shared log file, atomic
  writes)
• pipeline data sharing (producer-consumer)
• segmented file sharing
• Parallel I/O
• cooperative appending
• segmented file sharing
• Other cases from our canonical grid examples?
• Distributed supercomputing
• Remote Real-time Instrumentation
• Tele-immersive
• Data Intensive

28
Alternatives

• UFO
• exploit Unix debugging (sproc) interface
• capture all filesystem references and redirect
• unify the remote and streaming accesses with the
  standard filesystem namespace
• allow system control of the namespace (a la Plan
  9) compatible global namespace portability
• WebFS
• synthesize a unified filesystem namespace
  interception and substitution at the vnode layer
• redirect certain accesses to a user-level demon
  running http
• access remote files using GET and PUT (sometimes
  supported)
• Traditional Distributed Filesystems
• NFS
• AFS (whole file caching)
• DFS (Windows filesystem redirection)

29
Discussion

• What are we giving up?
• How does this differ from a conventional
  distributed filesystem?
• How does this differ from our typical model of
  storage?
• How does this compare to the WWW as a storage
  system?
• How much does this help an application
  programmer?
• Does this express I/O activity in a way that is
  amenable to system optimization?
• Other Questions?

30
Summary

• Grid Security Requirements and Globus
  Infrastructure
• Significantly different requirements than
  traditional security
• Not two-party (client-server) focused heavy
  reliance on proxies
• Grid and local identity and credentials Trusted
  mappings and Resource Proxies
• Group identity and interaction
• GASS Global Access to Secondary Storage
• Synthesizes a global namespace (not the same as
  any other)
• Uses similar primitives for I/O (but not the same
  as any other)
• can distinguish Grid I/O from traditional
• can control caches and do explicit management
• Optimization of common cases by building standard
  primitives (e.g. globusrun to stage executables)

31
Next Time

• Additional Input/output and Filesystem Readings
• FC, Chapter 5, Data-Intensive Computing
• WebOS Operating System Services For Wide Area
  Applications,'' Seventh Symposium on High
  Performance Distributed Computing July 1998.
• WebFS a Global Cache Coherent Filesystem, UCB
  Tech report
• Alexandrov, et. Al. Extending the Operating
  System at the User Level the UFO Global File
  System, 1997 Annual Technical Conference on Unix
  and Advanced Computing Systems (USENIX 97),
  January 1997
• Next Time
• A Fault Detection Service for Wide Area
  Distributed Computations, Proc. 7th IEEE Symp.
  on High Performance Distributed
  Computing, 1998.
• Discussion about Projects and Initial Project
  Assignment
• (email and web information forthcoming)