simplifying and securing your openshift network with project calico

1© 2017 Tigera, Inc. | Proprietary and Confidential

OpenShift Commons BriefingAndy Randall, CEO

Simplifying and Securing Your OpenShift Network with Project Calico

March 2, 2017


Isn’t virtual networking a solved problem?

Can we just get on with developing and deploying apps now?

First, a (not unreasonable) question...


Challenges of Cloud-Native: Scale & Churn

<0.1xMedian lifespan

>10xWorkloads per host

100+xChurn per host

First-generation, centralized SDN controller

Traditional security appliance


Challenges of Cloud-Native: Dynamic SecurityDynamic IP address assignment

Fungible server resources

Subnets / VLANs no longer meaningful for security rules

Orchestrator makes highly dynamic scheduling decisions

Workload meta-data already captured in orchestrator

Opportunity to automate security, get rid of “firewall cruft”

Micro-services architecture increases network-based attack surface

Attackers already exploit internal vulnerabilities

Perimeter security insufficient — need to secure intra-cluster traffic


SIMPLIFY the network, by removing unnecessary layers of complexity

What’s Required?

… implemented in a scale-out, distributed architecture

… SECURE workloads with fine-grained policy rules, leveraging orchestrator


Enter Project Calico

Thousands of clusters deployed globally by users such as...

Active open source community with 100+ contributors


1. Simplify the Network

☑ Flat IP network (pods are endpoints too)

☑ No overlay by default ⇒ zero packet overhead

☑ Routed model — one hop to the kernel, another hop to the destination (remote kernel or local pod)

☑ Leverages Linux’s built-in, efficient network stack

☑ Maximum performance, simplest to troubleshoot


Calico Architecture: Routing

Physical fabric (L2 or L3) or public cloud SDN (e.g. Amazon VPC / subnet)

Cloud OS / Orchestration SystemCloud OS / Orchestration System

Compute NodeCompute NodeCompute Node

kernel

Cloud OS / Orchestration System

Calico-node

Routes

Pod

Eth0

CalicoPlugin


kernel

Calico-node

Routes

Pod

Eth0

Control plane (etcd / Raft + BGP)

Data plane (IP)


Calico Architecture: Policy Enforcement

Physical fabric (L2 or L3) or public cloud SDN (e.g. Amazon VPC / subnet)



kernel


Calico-node

Routes ACLs

Pod

Eth0

CalicoPlugin


kernel

Calico-node

Routes ACLs

Pod

Eth0

Control plane (etcd / Raft + BGP)

Data plane (IP)


2. Network Policies

My IT guys installed a firewall at the edge of my data center. Why do I want network policies as well?


Anatomy of a Calico Network Policy

apiVersion: v1kind: policymetadata: name: allow-tcp-6379spec: selector: role == 'database' ingress: - action: allow protocol: tcp source: selector: role == 'frontend' destination: ports: - 6379 egress: - action: allow

Name of this policy

Which pods does it apply to?

Who can talk to those pods (with which protocols?)

To whom can those pods talk (with which protocols?)

$ calicoctl apply -f mypolicy.yaml

API versionYes, this looks a lot like a Kubernetes Network Policy…Calico can enforce k8s policy or this extended model


Calico Architecture: Policy Enforcement Revisited



kernel


Calico-node

Routes ACLs

Pod

Eth0

CalicoPlugin


kernel

Calico-node

Routes ACLs

Pod

Eth0

■ Policy rendering to ACLs is distributed to calico agents

■ Each node efficiently calculates what it needs & programs iptables

■ At scale, <10ms to first ping


Architectural ComparisonOVS-based (e.g. OpenShift SDN) Project Calico

One subnet per host Dynamic allocation of IP address ranges to host as additional containers scheduled (reduces wasted addresses without imposing an upper limit on # containers)

Pods connected to OVS Bridge (br0) Pods connected into Linux kernel routing engine (no bridge, single routed hop, same path intra/inter node)

Access to pods on remote nodes via VXLAN tunnel (tun0)

Tunnel possible but not required — pods have real IPs on underlying network — no double-encapsulation when running on underlying SDN (e.g. public cloud or OpenStack)

Connectivity outside cluster via NAT NAT not required by default to outside world, since pods have real IPs

Network isolation enforced in OVS via tenant separation (separate ovs-multitenant plug-in) or Kubernetes network policy with ovs-subnet

Network isolation (including multi-tenant) enforced via ingress + egress policy rules encoded into iptables rules in Linux kernel

OVS in control and data path Calico in control path only (data path = traditional Linux kernel L3 forwarding & filtering)


Considerations for other SDN solutions(Some) Other Networking Solutions Project Calico

Centralized controller calculates rules for each node All policy calculations / rendering

Must replace internal service routing — not compatible with Kube-proxy

Fully compatible with standard Kube-proxy

Must use own external load balancing — not compatible with OpenShift Router

Fully compatible with OpenShift Router and any other regular IP networking mechanisms (it’s just IP)


Can I just get the policies?

I like how Calico does policies — but still want to use a VXLAN overlay.

You probably can’t do that, right?


Combining Calico with Flannel NetworkingA collaboration between Tigera and CoreOS to apply Calico policy to flannel overlay networks

More: http://github.com/projectcalico/canal


Calico & OpenShift

So how does this all tie together with

?


Calico on OpenShift


Calico on OpenShift

CNI CNI CNI

CNI CNI CNI

● Calico-CNI

● Calico-IPAM

CNI


Calico on OpenShift

CNI CNI CNI

CNI CNI CNI

● Felix (local routing & policy calculation)

● Bird (BGP)

Calico/Node


Calico on OpenShift

CNI CNI CNI

CNI CNI CNI

P Calico Policy Controller


Lots of recipes Calico + Kubernetes■ E.g. AWS Quick Start, Stack Point Cloud, kops, ...

Users have deployed with OpenShift ■ “Roll-your-own” installation until recently

Tigera / Red Hat collaborating on supported integration and certification for OpenShift

■ Integration was working - but broken by OCP 3.4. Addressing a few minor remaining issues.

■ “Watch this space” - by signing up to the Project Calico Slack (http://slack.projectcalico.org), joining the #openshift channel, and let us know you’re interested!

Calico-OpenShift Integration

&

http://slack.projectcalico.org


github.com/projectcalico

@andrew_randall | @projectcalico

slack.projectcalico.org → #openshift

Andy [email protected]

simplifying and securing your openshift network with project calico

Technology