Wp4 gridification security components in the fabric overview of the wp4 architecture as of d4 2
1 / 12

WP4 Gridification Security Components in the Fabric overview of the WP4 architecture as of D4.2 - PowerPoint PPT Presentation

  • Uploaded on

WP4 Gridification Security Components in the Fabric overview of the WP4 architecture as of D4.2. f or Gridification Task : David Groep hep-proj-grid-fabric -gridify @cern.ch. Fabric security components. External (“Grid”) components

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'WP4 Gridification Security Components in the Fabric overview of the WP4 architecture as of D4.2' - fay

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Wp4 gridification security components in the fabric overview of the wp4 architecture as of d4 2

WP4 GridificationSecurity Components in the Fabricoverview of the WP4 architecture as of D4.2

for Gridification Task: David Groep


Fabric security components
Fabric security components

  • External (“Grid”) components

    • issues relating to the three core Grid protocols (GRAM, GSIFTP,GRIP)

    • network issues (firewall admin, NAT)

    • fabric authorization interoperability (multi-domain, AAA, co-allocing)

  • Internal components

    • authenticated installation services

    • secure bootstrapping services

Job submission protocol interface
Job submission protocol & interface

  • Current design

    • Client tools connect to gatekeeper

    • GRAM (attributes over HTTPS)

    • Gatekeeper does authentication, authorization and user mapping

    • RSL passed to JobManager

  • Identified design differences

    • authorization and user mapping done too early in process

  • Identical components

    • Protocol must stay the same (GRAM)

    • Separation of JobManager (closer to RMS) and GateKeeper will remain

  • Issues: scalability problems with many jobs within one centre (N jobmanagers) authorization cannot take into account RMS state (budget, etc.)

Authorization and aaa

Current design:

Authorization and user mapping are combined (see next slide)

Local local site policy in authorization

Identified design points

new component, taking concepts from generic AAA architectures

coordinate with AuthZ group and GGF

Identical components

towards generic AAA architectures/servers(LCAS will be like an ASM)

distributed AAA decisions/brokering

concepts from new SciDAC/SecureGRID/AAAARCH work

Authorization and AAA

Accounting framework yet to be considered…

Credential mapping
Credential Mapping

  • Current design:

    • Authorization and user mapping are combined

    • Gatekeeper map file with GridMapDir (on connection establishment)

    • Kerberos by external service (sslk5)

  • Identified design points

    • move to later in the process (after the authorization decision)

    • Extend for multiple credential types…

  • Identical components

    • gridmapdir patch by Andrew McNab

    • sslk5/k5cert service

  • Issues in current design

    • mapping may be expensive (updating password files, NIS, LDAP, etc.)

Local security service flids
Local security service (FLIdS)

  • Current design:

    • Component is not Gridcomponent→not there

    • Technology ubiquitous (X.509 PKI)

  • Identified design points

    • Policy driven automatic service

    • policy language design (based on generic policy language or ACLs)

  • Identical components

    • PKI X.509 technology (OpenSSL)

    • use by GSI and HTTPS

  • Issues:

    • mainly useful in untrusted environments (e.g., outside a locked computer centre)

    • prevents CA overloading…

Non-critical for grid servicesneeded for intra-fabric security

Information services grifis
Information Services (GriFIS)

  • Current design:

    • MDS2.1: LDAP protocol with back-endsor F-Tree

    • Modular information providers

  • Identical components

    • NO fundamental changes by WP4

    • GIS/Ftree and/or GMA/R-GMA or …

    • Just More information providers

    • Correlators between RMS, Monitoring and CDB (internal WP4 components)

  • Issues design

    • How will global scheduling decisions be made (AAA-wise)?

    • distributed AAA based on new standard

    • future for LCAS

Network access to large fabrics
Network access to large fabrics

  • Current Globus design

    • Is not in scope of Globus toolkit

  • Identified issues

    • Needed component for large farms

    • Needed for bandwidth provisioning,brokerage & selective firewall adminning

    • Farm nodes not visible from outside!

  • Identical components

    • 0st order: no functionality

    • 1st order: IP Masquerading routers

    • 2nd order: IP Masq & protocol translation (IPv6 → IPv4 and v.v.)

    • later: use of intelligent edge devices, managed bandwidth (and connections) per job, AAA interaction (with LCAS)

Intra fabric security issues
Intra-fabric security issues

  • How to install a node in an untrusted network environment

    • distribution of sensitive config data (SSH host keys)

    • integrity of configuration data

    • bootstrapping problem!

  • Secure install scenario requires a local quasi-CA(FLIdS = Fabric-Local Identity Service)

  • See use-case on next slide (don’t be terrified by the arrows…)

Bootstrapping a machine on a hostile net

CFG Configuration Database

LCA root cert

CFG data ACLs

11: CFG web server can checkhostname in cert againstrequesting IP addressand check ACLs

Secured http server

7: FLIDS checks signature of operator, and signsrequest with LCA key. Request DN namespace limited.

3:https server checks CFG data ACL(operator has all rights), can verify IDof operator using LCA root cert

FLIDS engine

4: sens config data encryptedusing session key

LCA cert and privkey

Automated CA,

Will sign when request

Approved by `operator’

2:agent makes https requestusing operator credentials

New host to be installed

6: request sent to FLIDS engine,signed by operator key (in cleartext)(FLIDS hostname known from CFG data)

10: https requests to CFGauthenticated with newsigned host certificate

5: host generates key pair(but without a passphrase to protecting private part)

9: host checks signature on cert using the LCA root cert on the boot disk

8: signed host cert back to host (in clear)

  • Operator install disk:

  • kernel and init

  • CFG https agent

  • Signed cert of operator

  • Protected private key of operator

  • LCA root certificate

1:Operator boots system

Bootstrapping a machine on a hostile net

Component summary
Component Summary

  • LCAS

    • comprehensive local authorization taking RMS issues into account

    • accepted jobs WILL run

    • should evolve into an “ASM” to allow inter-domain co-allocation


    • take as much as possible from existing gridmapdir work, generalize for K5

  • FabNAT

    • 1st goal: solve addressing issue; later: managed firewalls etc; allow plug-in to LCAS

  • FLIdS

    • build secure fabrics on an insecure network (smaller uni’s etc.), prevent CA overload

  • Key is to stay compatible and interoperable!

    • GRAM protocol (& RSL) [Globus, GGF]

    • Information framework (GRIP, GMA, R-GMA, …) [Globus, GGF and EDG WP3]

    • All work on security in AAAARCH, PKIX, GGF sec. area, SecureGRID