Distributed File Systems Security: Anonymous access all files - PDF document

6/6/2017 Distributed File Systems Security: Anonymous access • all files available to all users 14B. Remote Data: Security – no authentication required – may be limited to read-only access 14C. Remote Data: Reliability & Robustness – examples: anonymous FTP, HTTP 14D. Remote Data: Performance • advantages 14E. Remote Data: Consistency – simple implementation 14F. Distributes Systems: Scalability • disadvantages – incapable of providing information privacy – write access often managed by other means Distributed Data - Performance, Robustness, Consistency 1 Distributed Data - Performance, Robustness, Consistency 2 Peer-to-Peer Security Server Authenticated Sessions • client-side authentication/authorization • client agent authenticates to each server – all users are known to all systems – session authorization based on those credentials – all systems are trusted to enforce access control – example: CIFS, authenticated HTTPS sessions – example: basic NFS • advantages • advantages – simple implementation – simple implementation • limitations • disadvantages – assumes all client systems can be trusted – may not work in heterogeneous OS environment – assumes all users are known to all systems – universal user registry is not scalable • UID mapping between heterogeneous OSs – no automatic fail-over if server dies • efficiency /scalability of universal user registries Distributed Data - Performance, Robustness, Consistency 3 Distributed Data - Performance, Robustness, Consistency 4 Domain Authentication Service example: KERBEROS • establishes secure client/server sessions • independent authentication of client & server • based on digital signatures – each authenticates with authentication service – every agent has a secret (symmetric) key – keys are known only to agent, and KERBEROS – each knows/trusts only the authentication service • request to KERBEROS encrypted w/client key • authentication service issues signed “tickets” – KERBEROS can decrypt it, authenticating requester – assuring each of the others’ identity and rights • KERBEROS response is two-part work ticket – may be revocable or have a limited life-time – part 1: encrypted with client's key • a symmetric session key • may establish secure two-way session • part 2 (to be forward, by client, to server) – privacy – nobody else can snoop on conversation – part 2: encrypted with server's key • client ID, ticket duration, – integrity – nobody can generate fake messages • symmetric session key Distributed Data - Performance, Robustness, Consistency 5 Distributed Data - Performance, Robustness, Consistency 6 1

6/6/2017 KERBEROS Work Tickets Distributed Authorization Authentication Client Server • Authentication service returns credentials Service request – which server checks against Access Control List client ID generate session key server ID – advantage: auth service doesn’t know about ACLs expiration time C-ticket S-ticket • Authentication service returns Capabilities session key session key server ID client ID – which server can verify (by signature) expiration time expiration time – advantage: servers do not know about clients encrypt w/server key decrypt w/client key encrypt w/client key decrypt w/server key • Both approaches are commonly used – credentials: if subsequent authorization required subsequent communication encrypted w/symmetric session keys – capabilities: if access can be granted all-at-once – either may have an expiration time Distributed Data - Performance, Robustness, Consistency 7 Distributed Data - Performance, Robustness, Consistency 8 Robustness: Embracing Failure Reliability and Availability • Failures are inevitable • Reliability … probability of not losing data – more components have more failures – disk/server failures to not result in data loss • RAID (mirroring, parity, erasure coding) – complex systems have more modes of failure • copies on multiple servers – we cannot build perfect components or systems – automatic recovery (of redundancy) after failure • We must build robust systems • Availability … fraction of time service available – additional capacity to survive failures – disk/server failures do not impact data availability – automatic failure detection • backup servers with automatic fail-over – dynamically adapt to the new reality – automatic recovery (back up to date) after rejoin – continue service, despite component failures Distributed Data - Performance, Robustness, Consistency 9 Distributed Data - Performance, Robustness, Consistency 10 Problems and Solutions Availability: Fail-Over • Network Errors – support client retries • data must be mirrored to secondary server – RFS protocol uses idempotent requests • failure of primary server must be detected – RFS protocol supports all-or-none transactions • client must be failed-over to secondary • Client Failures – support server-side recovery – automatic back-out of uncommitted transactions • session state must be reestablished – automatic expiration of timed out lock leases – client authentication/credentials • Server Failures – support server fail-over – session parameters (e.g. working directory, offset) – replicated (parallel or back-up) servers • in-progress operations must be retransmitted – stateless RFS protocols – client must expect timeouts, retransmit requests – automatic client-server rebinding – client responsible for writes until server ACKs Distributed Data - Performance, Robustness, Consistency 11 Distributed Data - Performance, Robustness, Consistency 12 2

6/6/2017 Reliability: Data Mirroring Availability: Failure Detect/Rebind • client driven recovery secondary – client detects server failure (connection error) – client reconnects to (successor) server Back-side Mirroring client primary – client reestablishes session secondary • transparent failure recovery – system detects server failure (health monitoring) secondary – successor assumes primary’s IP address Front-side Mirroring – state reestablishment client primary • successor recovers last primary state check-point • stateless protocol secondary Distributed Data - Performance, Robustness, Consistency 13 Distributed Data - Performance, Robustness, Consistency 14 Availability: Stateless Protocols Availability: Idempotent Operations • a statefull protocol (e.g. TCP) • can be repeated many times with same effect – operations occur within a context – read block 100 of file X – each operation depends on previous operations – write block 100 of file X with contents Y – delete file X version 3 – successor server must remember session state – non-idempotent operations • a stateless protocol (e.g. HTTP) • read next block of current file – client supplies necessary context w/each request • append contents Y to end of file X • if client gets no response, resend request – each operation is complete and unambiguous – if server gets multiple requests, no harm done – successor server has no memory of past events – works for server failure, lost request, lost response • stateless protocols make fail-over easy • but no ACK does not mean operation did not happen Distributed Data - Performance, Robustness, Consistency 15 Distributed Data - Performance, Robustness, Consistency 16 (nearly) Stateless Protocols Performance Challenges • single client response-time • client can maintain the session state – remote requests involve messages and delays – e.g. file handles and current offsets – error detection/recovery further reduces efficiency • aggregate bandwidth • write operations can be made idempotent A 3 – each client puts message processing load on server – e.g. associate a client XID with each write – each client puts disk throughput load on server • idempotence doesn’t solve multi-writer races – each message loads server NIC and network • WAN scale operation – competing writers must serialize their updates A 4 – where bandwidth is limited and latency is high – clients cannot be trusted to maintain lock state • aggregate capacity • we need a state-full Distributed Lock Manager – how to transparently grow existing file systems – for whom failure recovery is extremely complex Distributed Data - Performance, Robustness, Consistency 17 Distributed Data - Performance, Robustness, Consistency 18 3