1 / 73

CloudPolice : Taking Access Control Out of the Network

CloudPolice : Taking Access Control Out of the Network. Lucian Popa Minlan Yu Steven Y. Ko UC Berkeley/ICSI Princeton Univ. Princeton Univ. Sylvia Ratnasamy Ion Stoica Intel Labs Berkeley UC Berkeley. Context.

powa
Download Presentation

CloudPolice : Taking Access Control Out of the Network

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. CloudPolice: Taking Access Control Out of the Network Lucian PopaMinlan Yu Steven Y. KoUC Berkeley/ICSI Princeton Univ. Princeton Univ. Sylvia Ratnasamy Ion StoicaIntel Labs Berkeley UC Berkeley

  2. Context • Infrastructure as a Service virtualized clouds • Traffic internal to cloud VM VM VM Hypervisor

  3. Context • Cloud computing requires network access control

  4. Context • Cloud computing requires network access control • Access control policy of tenant X = what network traffic is tenant X willing to accept Y can talk to me Tenant X Tenant Y

  5. Why Access Control in Clouds? (1) • For isolation • Policy: deny incoming traffic from any other tenant Exbay Amazonia

  6. Why Access Control in Clouds? (2) • For inter-tenant & tenant-provider communication • Policy: allow/deny traffic from specific tenants • Increasingly common in cloud environments • Low latency and high bandwidth • Ease of service composition Exbay Amazonia

  7. Why Access Control in Clouds? (2) • For inter-tenant & tenant-provider communication • Policy: allow/deny traffic from specific tenants Exbay Amazonia Real-time bidding advertising

  8. Why Access Control in Clouds? (2) • For inter-tenant & tenant-provider communication • Policy: allow/deny traffic from specific tenants Send information about client Exbay Amazonia Ad Networks Ad Network 2 Ad Network 1 Real-time bidding advertising

  9. Why Access Control in Clouds? (2) • For inter-tenant & tenant-provider communication • Policy: allow/deny traffic from specific tenants Receive ad bids Exbay Amazonia Ad Networks Ad Network 2 Ad Network 1 Real-time bidding advertising

  10. Why Access Control in Clouds? (2) • For inter-tenant & tenant-provider communication • Policy: allow/deny traffic from specific tenants Return ad of highest bidder Exbay Amazonia Ad Networks Ad Network 2 Ad Network 1 Real-time bidding advertising

  11. Why Access Control in Clouds? (2) • For inter-tenant & tenant-provider communication • Policy: allow/deny traffic from specific tenants Policy of Exbay: allow traffic from AdNetworks, deny all other traffic Exbay Amazonia Ad Networks Ad Network 2 Ad Network 1 Real-time bidding advertising

  12. Why Access Control in Clouds? (2) • For inter-tenant & tenant-provider communication • Policy: allow/deny traffic from specific tenants • Other service examples: database (SimpleDB), desktop, communication (SQS), map-reduce++, Facebook, host managing, locking, etc. Exbay Amazonia Ad Networks Ad Network 2 Ad Network 1

  13. Why Access Control in Clouds? (3) • For inter-tenant & tenant-provider communication • Policy: weighted bandwidth allocation between tenants Exbay Amazonia Ad Networks Ad Network 2 Ad Network 1

  14. Why Access Control in Clouds? (3) • For inter-tenant & tenant-provider communication • Policy: weighted bandwidth allocation between tenants Share bandwidth fairly among tenants regardless of #VM sources Exbay Nextbay Amazonia Ad Networks Ad Network 2 Ad Network 1

  15. Why Access Control in Clouds? (3) • For inter-tenant & tenant-provider communication • Policy: weighted bandwidth allocation between tenants • Other example policies: • Rate-limited access • Allow only locally initiated connections • Nighttime access only Exbay Nextbay Amazonia Ad Networks Ad Network 2 Ad Network 1

  16. Why Access Control in Clouds? (4) • DoS protection • One tenant can attack another tenant • Reduce bandwidth and slow down machines • Attackers more powerful: higher bandwidths • Barrier is lower: pay for attacking hosts (compromise credit cards instead of hosts) Exbay Nextbay AmazoniaX Ad Networks Ad Network 2 Ad Network 1

  17. Hence, the problem • Want access control in clouds that • Is resilient to DoS • Supports rich inter-tenant policies

  18. Hence, the problem • Want access control in clouds that • Is resilient to DoS • Supports rich inter-tenant policies • Scales • 100k servers • 10k tenants

  19. Hence, the problem • Want access control in clouds that • Is resilient to DoS • Supports rich inter-tenant policies • Scales • Tolerates high dynamicity • 100k VMs started per day, more than one per second

  20. Hence, the problem • Want access control in clouds that • Is resilient to DoS • Supports rich inter-tenant policies • Scales • Tolerates high dynamicity • Traditional access control mechanisms not well suited to meeting these requirements

  21. Existing Access Control • Cloud APIs are narrow • On/off • No locally initiated connections, no rate-limiting, no weighted allocation • Mechanisms inherited from enterprises • VLANs • Firewalls

  22. Existing Access Control • Cloud APIs are narrow • On/off • No locally initiated connections, no rate-limiting, no weighted allocation • Mechanisms inherited from enterprises • VLANs • Firewalls • But clouds != enterprises

  23. Clouds != Enterprises • Enterprises are not multi-tenant • FewDoSconcerns between departments • Typically simpler policies • Enterprises don’t have the same dynamicity and scale • 10k tenants vs. 10s departments; 1 VM/s vs. mostly static • Clouds have different network designs • High bisection bandwidths, multiple paths, different L2/L3 mix • Many new topologies: FatTree, VL2, BCube, DCell, etc.

  24. VLANS not well suited for clouds • Inflexible policies • Difficult to scale (cloud size & dynamicity) • Limited number, spanning tree • Limited network designs • No L3 networks, no multiple paths, inter-VLAN through router

  25. Firewalls not well suited for Clouds • Offering DoS protection is difficult • Must be applied at source  hard to update • Inflexible policies • Scale through prefix aggregation • Difficult to manage • 10k tenants with multiple prefixes, different scaling requirements • No L3 networks

  26. Recap • Traditional access control is not well suited for clouds • Couple access control with network operation • With switching – VLANs • With address assignment – Firewalls

  27. Recap • Traditional access control is not well suited for clouds • Couple access control with network operation • With switching – VLANs • With address assignment – Firewalls • CloudPolice takes access control out of the network

  28. Outline • Part 1 – Context and Motivation • Access control for clouds: why and what? • Limitations of traditional mechanisms • Part 2 – CloudPolice • Approach • Operation Cloud Police

  29. Goal Network Access Control for Clouds that is: • Independent of network topology and addressing • Scalable (millions hosts, high churn) • Flexible (on/off access, rated access, fair access) • Robust to (internal) DDoS attacks

  30. CloudPolice • Sufficient and advantageous to implement access control only within hypervisors VM VM VM Hypervisor

  31. CloudPolice • Sufficient and advantageous to implement access control only within hypervisors • Trusted • Network independent • Full software programmability  flexible • Close to VMs  block unwanted traffic before network and help DoS • Easy deployability VM VM VM Hypervisor

  32. CloudPolice • Sufficient and advantageous to implement access control only within hypervisors CloudPolice Policy Model • Group= set of tenant VMs with same access control policy VM VM VM Hypervisor

  33. CloudPolice • Sufficient and advantageous to implement access control only within hypervisors Policy = set of Rules Rule = IF Condition THEN Action CloudPolice Policy Model VM VM VM Hypervisor

  34. CloudPolice • Sufficient and advantageous to implement access control only within hypervisors • Condition = logical expression with predicates based on: • Group of sender • Packet header • Current time • History of traffic CloudPolice Policy Model VM VM VM Hypervisor

  35. CloudPolice • Sufficient and advantageous to implement access control only within hypervisors • Action: • Allow • Block • Rate-limit (token bucket) CloudPolice Policy Model VM VM VM Hypervisor

  36. CloudPolice • Sufficient and advantageous to implement access control only within hypervisors • Action: • Allow • Block • Rate-limit (token bucket) CloudPolice Policy Model VM VM VM flow Applied per source VM Hypervisor source group

  37. CloudPolice • Hypervisor-based VM VM Dst.VM VM VM Src.VM Hypervisor Hypervisor

  38. CloudPolice • Hypervisor-based • Avoid DoS and wasted resources  apply policy at source VM VM Dst.VM VM VM Src.VM Hypervisor Hypervisor

  39. CloudPolice • Hypervisor-based • How to apply destination’s policy at the source hypervisor? VM VM Dst.VM VM VM Src.VM Hypervisor Hypervisor

  40. CloudPolice • Hypervisor-based • Centralized policy repository? VM VM Dst.VM VM VM Src.VM Hypervisor Hypervisor

  41. CloudPolice • Hypervisor-based • Centralized policy repository? VM VM Dst.VM VM VM Src.VM Allow? Hypervisor Hypervisor

  42. CloudPolice • Hypervisor-based • Centralized policy repository? • Centralized service requires high availability and throughput • 100k servers and 10 new flows/VM/s  1M decisions/s on average! • Caching can be ineffective (random patterns, malicious pollution) • Centralized service can be a DoStarget VM VM Dst.VM VM VM Src.VM Allow? Hypervisor Hypervisor

  43. CloudPolice • Hypervisor-based • Decentralized VM VM Dst.VM VM VM Src.VM Hypervisor Hypervisor

  44. CloudPolice • Hypervisor-based • Decentralized • Distribute all policies to all hypervisors? VM VM Dst.VM VM VM Src.VM Hypervisor Hypervisor

  45. CloudPolice • Hypervisor-based • Decentralized • Distribute all policies to all hypervisors? VM VM Dst.VM VM VM Src.VM Hypervisor Hypervisor Allow?

  46. CloudPolice • Hypervisor-based • Decentralized • Distribute all policies to all hypervisors? • Too heavyweight if network independent • Full group membership required; Group updates propagated everywhere • 100k new VMs/day, 100k servers  100k updates/s on average VM VM Dst.VM VM VM Src.VM Hypervisor Hypervisor

  47. CloudPolice • Hypervisor-based • Decentralized • Apply at destination and enforce at source VM VM Dst.VM VM VM Src.VM Apply destination’s policy Hypervisor Hypervisor

  48. CloudPolice • Hypervisor-based • Decentralized • Apply at destination and enforce at source VM VM Dst.VM VM VM Src.VM Enforce policy’s action Hypervisor Hypervisor

  49. Inspired by Internet Research • Internet solutions to DDoS • Push-back filters [AIP, Pushback, AITF, StopIt] • Network Capabilities [SIFF, TVA] • Handle large and dynamic networks, millions of users

  50. Inspired by Internet Research • Internet solutions to DDoS • Push-back filters [AIP, Pushback, AITF, StopIt] • Network Capabilities [SIFF, TVA] • Handle large and dynamic networks, millions of users • More easily deployed: Clouds != Internet • Clouds are controlled environments • Both communication endpoints can be controlled • Single administrative domain • New tools: trusted software layer – Hypervisor

More Related