1 / 20

Towards Cloud Federations: what we have; what we want

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

gaille
Download Presentation

Towards Cloud Federations: what we have; what we want

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. 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

  2. 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

  3. …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

  4. …and more new security issues • Over-allocation of dynamic resources • Intentional – scheduling DoS attack (with stolen account) • Unintentional – runaway jobs

  5. 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

  6. What is the Federation • Group of service providers • Providing “e-infrastructure” • Coordinated deployment (maybe) • Agreeing to common policies • Support framework • Internal and user-facing

  7. 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

  8. Accounting • Resource used • Billing • Make use of user’s own account with commercial providers (alternative: hold user’s credit card)

  9. 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.)

  10. 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

  11. 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

  12. 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: topnationalinst.person • Scalability + resilience (up to a point)

  13. 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?)

  14. 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

  15. Authentication into federation Base login on existing infrastructures (when this makes sense)

  16. Accounting

  17. 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

  18. 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

  19. 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

  20. 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

More Related