The document discusses the challenges of providing secure networking in public and private cloud environments. It notes that security is difficult because connectivity needs to be provided by default while preventing unwanted connections, and that security policies are harder to apply than just enabling connectivity. The document also examines issues like tenant isolation, application isolation, multitenant challenges, identity and location-based security approaches, and how to better integrate security capabilities into cloud platforms like OpenStack. It argues that security must be designed into networks from the beginning as an integrated system rather than added as an afterthought.

1. The Role of Networking in building
Secure Public/Private Clouds
Pere Monclus
Oct 18th, 2012
pmonclus@plumgrid.com

2. Networking Dilemma
Prevent Unwanted Provide
Connectivity Connectivity
(default closed) (default open)
A matter of Policy
 QoS ∞ QoS
QoS
2

3. Why so hard? (part 1)
Midsize Enterprise Network diagram (Cisco Safe guides)
WHERE to apply Security Policies is harder than Connectivity
3

4. The approach to Security
Designing Network Security
• Adding Security as a self contained element
Designing Secure Networks
• Incorporate Security from the beginning
Network Security is a System !!
4

5. Why so hard? (part 2)
The problem doesn’t start at Network Security …
Business Needs
Risk Analysis
Security Policies
Security System
… often is expected to be solved by a Network Service
5

6. And… what about Cloud?
Tenant 1 Tenant 2 Tenant 3
Business Needs Business Needs Business Needs
Risk Analysis Risk Analysis Risk Analysis
Security Policies Security Policies Security Policies
Security System Security System Security System
Users / Tenants
Infrastructure
Guarantees
Public / Private
Cloud provider Superset of
Business Needs
requirements
Risk Analysis
Security Policies
Security System
6

7. Cloud Provider: Tenant Isolation
Provider
Tenant Tenant Tenant
Internet Control
1 2 3 Infrastructure
Cloud Provider
Multitenancy
Isolation Self Provisioning
Cloud Services
7

8. Tenant: Networking Application Isolation
Inbound/Outbound policies
10.0.1.0/24 10.0.2.0/24
VM VM VM VM
Interface attached network security policies
Services: FW, VPN, IPS, UTM, … (pics!)
Is this the right model in a virtual world?
8

9. What is Isolation? What SLA are we willing to sign up to?
• Subnet separation?
• Security rules?
• Security services (FW/IPS/UTM/…)
Tenant
• • Enforcement points?
Tenant Inbound/Outbound enforcement? owns?
• Common/Separate?
• …
• New types
• How to merge policies?
• Network separation? Physical? Virtual? Provider
• owns?
Transit Policies? • Policy definition vs. Policy Rendering?
• Data Leakage?
• Proper workflows
• Physical Placement?
• Traffic confidentiality?
• ...
9

10. Security Life Cycle
What about?
• System Monitoring and Maintenance
• Compliance Checks
• Incident Response
• Forensics / Visibility / Analysis tools
Who owns that?
How do we cross from Provider to Tenant and we still
provide simple operational models?
10

11. Network security and OpenStack
11

12. OpenStack Quantum Model
Network
Controller
Management Network
Compute
Network Node(s) Quantum server
quantum-*-plugin-agent
Compute Node(s) Cloud Controller Networking
quantum-l3-agent
Node
quantum-dhcp-agent
quantum-*-plugin-agent
Storage
Virtual Network
Data Network
Physical Network
* from Quantum Admin guide
12

13. OpenStack Network Types
Virtual Virtual Local
Network Ports Network
Tenant
(VMs) Networks
Linux Overlays Tenant
Bridges Networks
Provider
Physical Physical Networks
Network Ports Flat
VLANs
Network
(Servers)
13

14. Spoofing/MiM v2.0 (Provider Worries)
Can I compromise/impersonate a VM/Server/Port?
• How to prevent the provisioning of a rogue Server
• How to prevent the provisioning of a rogue VM
• How to prevent the provisioning of a rogue Port / Taps
But… if it happens:
• How to prevent the ‘connectivity’ of a rogue Server / VM / Port to
a physical or logical network
* Not to enter into discussions about securing the Cloud Controller
14

15. Application Policy Management (Tenant Worries)
In a Virtual environment:
• Policy definition
• Policy Rendering
• Policy Enforcement
• Security Services Offering (Virtual Appliances)
15

16. Identity and Location to the rescue
Understanding the linkage between Physical and Virtual
Understanding the linkage between Identity and Address
16

17. Multisite Clouds
Physical/Virtual and Identity/Address expand across Datacenters
17

18. Possible steps to integrate Security in OpenStack
• Service Insertion (Choke points at the Operator and Tenant level)
• Physical Appliances
• Virtual Appliances
• Distributed Appliances
• New policy capabilities
• Applied at the VM ifc level (definition-rendering problem)
• Identity based
• Proper articulation of Virtual/Physical bindings
• Cloud Controller workflows for security
• Discussion on where to apply/attach global policies
• What SLAs and Certifications will the Tenants expect?
18

19. Conclusion
• No easy answer to Security
• Blurring the line between Virtual and Physical
networks brings many additional challenges and
OPPORTUNITIES
• Centralized control structures are more vulnerable.
Need proper workflows.
• Incorporate Security from early stages, it is difficult to
bolt it in
19

20. Questions?
Pere Monclus
pmonclus@plumgrid.com
www.plumgrid.com
20