200 likes | 342 Views
Towards Cloud Federations: what we have; what we want. OGF 31, Taipei Cloud security session Jens Jensen Science and Technology Facilities Council Rutherford Appleton Laboratory. Clouds have “normal” security issues. Protect infrastructure against abuse Provider’s reputation
E N D
Towards Cloud Federations:what we have; what we want OGF 31, Taipei Cloud security session Jens Jensen Science and Technology Facilities Council Rutherford Appleton Laboratory
Clouds have “normal” security issues • Protect infrastructure against abuse • Provider’s reputation • User’s data, software, computations • Users’ credentials: loss, level of assurance • Fabric security • Open source vs closed source issues
…and new security issues • (Often) unknown resource location • Multitenancy: protect against other users • VM Image security: • Stale images • Maliciously modified images (or apps) • Install/patch window
…and more new security issues • Over-allocation of dynamic resources • Intentional – scheduling DoS attack (with stolen account) • Unintentional – runaway jobs
Cloud security vs Grid security? • In some sense, cloud = grid+elasticity • Elasticity poses security issues: dynamically created services • But grids have been there: eg WSRF • Web Services Resource Framework
What is the Federation • Group of service providers • Providing “e-infrastructure” • Coordinated deployment (maybe) • Agreeing to common policies • Support framework • Internal and user-facing
What is the Federation: user • Central account • Single sign-on (in some sense: single login) • Central accounting of all services • Enable collaborations • Traceability of user id • Intelligent resource selection/scheduling
Accounting • Resource used • Billing • Make use of user’s own account with commercial providers (alternative: hold user’s credit card)
Federation specific issues • Policies needed for establishing and maintaining trust in federations • Higher LoA in authentication? • Multiple jurisdictions for AAA, support, billing • … “solved” by the Grids • non-trivial • a process, not a single solution (like all sec.)
Providers: Prepared Protection Prevents Pricy Problems • Set the bar high enough to keep the bad guys out • Some bad guys are more resourceful and determined than others • Ensure legitimate users can still use the service (the bear/bin problem) • LoA – higher across national boundaries • Usually a single (high) LoA in grids
Practical Problems: the Practitioner Principle • “Normal” users just want to get their work done • (High) security gets in the way? • Well-known “usability vs security” • (Highlight (rare?) wins: increase both, eg SSO) • Multiple providers, heterogeneous security • Multitenancy – ensure service availability
How it works todaye-Infrastructure • Grid and e-Science infrastructures for authentication: IGTF PKI, Shib + superShib, … • X.509/RFC3280/GFD.125, SAML, OpenID • Delegation: RFC3820, SAML, Oauth • Authorisation: attribute authorities • RFC3281, SAML, (+VOMS) • Accounting:RUS • Support: helpdesks: topnationalinst.person • Scalability + resilience (up to a point)
Cloud world • Passwords, shared secrets • Vendor support • Easier security for small users? • Usability: we can bring grid portals to the cloud • Grids have mature federations; cloud feds being developed • Should clouds target only small users? (how should large users be handled?)
Gaps • Reuse grid federation infrastructure for federating clouds • Without losing being lightweight • Interoperation, of cloud services, with grids • Do IaaS and SaaS and PaaS have different security requirements? • Is the Grid LoA sufficient? Too high for some cases – maybe too low for others
Authentication into federation Base login on existing infrastructures (when this makes sense)
The CONTRAIL project • Federated cloud access • SLAs, QoS, QoP • Fully secured IaaS and PaaS • Using formal methods in some cases • EU funded (11 MEUR, a dozen partners or so) • Oct 2010-Sep 2013
CONTRAIL • FederatedCloud access: single account, with metering, billing, etc. • Access multiple IaaS and PaaS providers: cloudbursting built in • Dynamic SLA negotiation, QoS and QoP. Security as funded activity • Case studies have different requirements: Media, geographic data, real-time scientific processing, genomics
Contrail Issues • Federate, making use of existing infrastructures • Eg for authentication: IGTF PKI, Terena Shibboleth super-federation, site SSO? • Challenge: Work and ∫ with other projects • How to do delegation on multiple backend AuC • Support access to multiple service providers • Need for consistent information from SPs
Conclusion • We need cloud federation • We have grid federation • These are not the same, but there are overlaps • Align with other projects, interoperate • Standardise whenever possible