This document discusses securing microservices in CloudFoundry. It begins by noting the need for microsegmentation as applications move to the cloud and become more elastic. Traditionally defining firewall rules by IP address becomes unmanageable in this environment. The document then proposes defining policies based on application roles and grouping endpoints into policy-defined segments. It provides examples of defining policies by application groups rather than individual IP addresses, avoiding state explosion. This group-based policy approach allows for secure, scalable and intent-based policy definition.

1. Securing Micro Services in CloudFoundry
Brenden Blanco and Deepa Kalani

2. Need for Micro Segmentation
 Movement towards cloud native applications.
 Elastic nature of applications requires a more agile way of configuring
policies
 Operators would like to have an intuitive way of defining policies, based on
application roles and not ip addresses.
 Relying on traditional firewall rules will quickly make it unmanageable as
applications move around
 Move towards a whitelist model of policy definition, where one defines
acceptable information flow and everything else is blocked
2

3. IPTables to define Endpoint Policy - State Explosion
IP1->IP3
IP1->IP5
IP1->IP7
IP1->IP8
IP3->IP1
IP3->IP5
IP3->IP7
IP3->IP8
IP2->IP4
IP2->IP6
IP2->IP9
IP2->IP10
IP4->IP6
IP4->IP2
IP4->IP9
IP4->IP10
IP2->IP4
IP2->IP6
IP2->IP9
IP2->IP10
IP4->IP6
IP4->IP2
IP4->IP9
IP4->IP10
IP5->IP1
IP5->IP3
IP5->IP7
IP5->IP8
IP7->IP1
IP7->IP5
IP7->IP3
IP7->IP8
IP8->IP3
IP8->IP5
IP8->IP7
IP8->IP1
IP9->IP4
IP9->IP6
IP9->IP2
IP9->IP10
IP10->IP2
IP10->IP6
IP10->IP4
IP10->IP9
IP Table Rules

4. Group Based Policy - secure, scalable, intent based
4
Green->Green
Red->Red
Green->Green
Red->Red
Green->Green
Red->Red
IP1,IP3->Green
IP2,IP4-> Red
IP5,IP7->Green
IP6-> Red
IP8->Green
IP9,IP10-> RedEndpoint Groups
Policies

5. Policy specification for Cloud Foundry Applications
 Define Endpoints and EPGs (Applications are represented by Groups of
Endpoints)
 Policy definition is in the nature of applications.
 e.g. A_APP->A_DB 80 allow, B_APP->A_APP allow.
 Envision policy as a graph of application connectivity
5
A_App
B_APP C_APP
A_DB
DB_Ext

6. www.iovisor.org
IO Module, users perspective
6
IO Module
Management interface
- REST API
- Cli / config file
Interfaces
- Interface Type (Net, Tracing, Storage, …)
Something runs in kernel
Something runs in user space
Controllers live up here IO Modules
CatalogSearch for IO Mod
Download IO Mod
Somewhere in the cloud (iovisor.org)
there is a catalog of public IO Modules

7. www.iovisor.org
IO Module, developers perspective
7
IO Modules
Catalog
Publish new Modules
Somewhere in the cloud (iovisor.org)
there is a catalog of public IO Modules
Data Plane
Management
interface
- REST API
- Cli / config file
Interfaces
- Interface Type (Net, Tracing,
Storage, …)
Users interact with the Module
with:
User space helper
IO Module
Control Plane
(user space)
IO Module
Data Plane
(kernel)
IO Module
developer
IO Module
IOVisor
SDK
Clang / P4
Python, C, C++, Go, JS …

8. www.iovisor.org
IO Module, graph composition
8
IOVisor
Manager
Kernel attachment points
Kernel space
User space
Open repo of
“IO Modules”
Kernel
code
Kernel
code
• extending Linux Kernel capabilities
APIs to Controllers
Metadata

9. www.iovisor.org 9
Composing IO Modules

10. Policy Plugin with IO Visor
10
Overlay –
VXLAN
192.168.0.0/16 192.168.1.0/16
Linux Bridge
Vxlan Dev
C C C
Garden/1 - 10.244.18.3Garden/0 - 10.244.18.2
Linux Bridge
Vxlan Dev
C C C
Policy boundary

11. www.iovisor.org
Backup Slides
11

12. www.iovisor.org
Introducing IO Visor Project
12
Future of Linux Kernel IO
for software defined services
Led by initial contributions from
PLUMgrid
(Upstreamed since Kernel 3.16)
Evolution of Kernel
BPF & eBPF
(Berkeley Packet Filter)
“IO Visor will work closely with the Linux kernel community to advance universal IO extensibility for Linux.
This collaboration is critically important as virtualization is putting more demands on flexibility, performance
and security.
Open source software and collaborative development are the ingredients for addressing massive change in
any industry. IO Visor will provide the essential framework for this work on Linux virtualization and
networking.”
Jim Zemlin,
Executive Director, The Linux Foundation.

13. www.iovisor.org
IO Visor Project: What?
• A programmable data plane and development tools to simplify the creation of new
infrastructure ideas
• An open source project and a community of developers
• Enables a new way to Innovate, Develop and Share IO and Networking functions
Open Source & Community
Programmable Data Plane
1
2
• A place to share / standardize new ideas in the form of “IO Modules”
Repository of “IO Modules”
3
13

14. www.iovisor.org 14
IO Visor Project Use Cases Example: Networking
▪ IO Visor is used to build a fully
distributed virtual network across
multiple compute nodes
▪ All data plane components are
inserted dynamically in the kernel
▪ No usage of virtual/physical
appliances needed
▪ Example here
https://github.com/iovisor/bcc/tree/ma
ster/examples/distributed_bridge
Virtual/Physical
Appliances
Virtual Network
Topology in
Kernel Space