KubeCon EU 2016: Secure, Cloud-Native Networking with Project Calico
•Descargar como PPTX, PDF•
7 recomendaciones•2,117 vistas
Why does the network matter and why does it need to be simple (the 3am test)? Why should we build networks that scale to the extremes and how can we do that with proven technologies? Finally, how can we secure microservices, why should we bother, and what does this mean for developers and operators? Sched Link: http://sched.co/6BUR
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a KubeCon EU 2016: Secure, Cloud-Native Networking with Project Calico
Similar a KubeCon EU 2016: Secure, Cloud-Native Networking with Project Calico (20)
Más de KubeAcademy
Más de KubeAcademy (20)
Último
Último (20)
KubeCon EU 2016: Secure, Cloud-Native Networking with Project Calico
- 1. Secure, Cloud-Native Networking Simple, scalable, secure networking for Kubernetes Shaun Crampton, Core Developer, Project Calico @projectcalico 10th March 2016
- 9. Container Host Container Namespace Root Namespace Container Namespace eth0 eth0 192.168.0.45 10.0.0.1 eth0 10.0.0.2 IP Linux Kernel Routing (you already have this!) default via 192.168.0.1 dev eth0 192.168.0.0/24 dev eth0 src 10.0.2.15 10.0.0.1/32 dev cali34 scope global 10.0.0.2/32 dev cali89 scope global 10.0.1.0/26 via 192.168.0.29 dev eth0 10.0.2.128/26 via 192.168.0.131 dev eth0 veth pair (kernel version 2.6.24+) Containers on other hosts Containers on this host cali34 cali89
- 15. FBI director James Comey has said he believes Sony’s cyberattackers first breached the studio’s network in September, gaining access through a common tactic called “spear phishing”—duping an employee into clicking on an email attachment or a web link. …For more than two months Sony’s hackers roamed freely, identifying what they wanted to steal. This was possible because the studio, with few exceptions, didn’t segregate or provide extra security for even its most precious secrets. In effect, once the invaders made it past the network gates they could go anywhere they wanted because Sony hadn’t locked any doors. Inside the Hack of the Century by Peter Elkind, Fortune.com
- 22. Developer intent
- 24. Container Host Container Namespace Root Namespace Container Namespace eth0 eth0 192.168.0.45 10.0.0.1 eth0 10.0.0.2 IP Linux Kernel Filtering (iptables) (you already have this!) Per-container distributed firewall cali34 cali89
- 26. Client NS Default NS Mgmt NS F C B F B F UI
- 27. Client NS Default NS Mgmt NS F C B F B F UI
- 28. Turn on isolation… kubectl annotate ns default "net.alpha.kubernetes.io/network-isolation=yes" --overwrite=true kubectl annotate ns client "net.alpha.kubernetes.io/network-isolation=yes" --overwrite=true
- 29. Client NS Default NS Mgmt NS F C B F B F UI
- 30. admin-ui.yaml kind: NetworkPolicy apiVersion: net.alpha.kubernetes.io/v1alpha1 metadata: namespace: default name: allow-ui spec: podSelector: ingress: - from: - namespaces: role: management-ui Metadata Empty selector applies to all pods Allow from management namespace
- 31. Client NS Default NS Mgmt NS F C B F B F UI
- 32. backend-policy.yaml kind: NetworkPolicy apiVersion: net.alpha.kubernetes.io/v1alpha1 metadata: namespace: default name: backend-policy spec: podSelector: tier: backend ingress: - from: - pods: tier: frontend ports: - protocol: TCP port: 637 Allow from frontends on port 637 only Apply to backends
- 33. Client NS Default NS Mgmt NS F C B F B F UI
- 34. frontend-policy.yaml kind: NetworkPolicy apiVersion: net.alpha.kubernetes.io/v1alpha1 metadata: namespace: default name: frontend-policy spec: podSelector: tier: frontend ingress: - from: - namespaces: role: client ports: - protocol: TCP port: 80 Apply to frontends Allow from clients On port 80
- 35. Client NS Default NS Mgmt NS F C B F B F UI
- 37. Main project website: www.projectcalico.org Production plugin: https://goo.gl/pyNsIf Try out the demo: https://goo.gl/BYC97u Ansible playbooks from Kubespray https://docs.kubespray.io/ Public #slack https://calicousers-slackin.herokuapp.com/ Download & try it out We welcome your feedback and contributions Follow me @fasaxc Follow us @projectcalico
Notas del editor
- Hi everyone, and welcome! My name is Shaun Crampton and I’m a Core Developer on Project Calico.
- I’d like to begin by reminding you of something you already know: which is that networks matter. The application you want to build doesn’t fit on a single machine. Computers have gotten faster, but our ambitions have outstripped what a single host can handle. In previous generations of web application architectures, the network was the thing that allowed you to reach your users.
- Now, with REST APIs, microservices and the move to containerisation, it is integrally involved in the composition of the application itself. So, container networking is important.
- So, given we know that networks matter, what are the characteristics of the network that matter? Today I’m going to tell you about the three characteristics that come up again and again with our customers. But before we talk about the big three, let’s talk about the foundation: modern applications; cloud native applications speak the Internet Protocol, IP. They do not speak AppleTalk, IPX, NetBIOS, or any other crazy protocol. Ethernet is the dominant physical interconnect used in data centers, but applications do not interact directly over Ethernet, they speak IP. First thing that we think is important is operational simplicity. Let me start by giving you a counter example for why that matters and tell you how that links in with the IP-only approach.
- Few years ago, my colleague, Christopher was working at a bioinformatics company managing their OpenStack cluster. It came time to upgrade the cluster and networking broke. Now, Christopher is a network architect, with years of experience building intercontinental IP backbone networks. But 36 hours later, he has to admit defeat and roll back the upgrade.
- The network model they were using was just too complex to diagnose, with lots of baggage to support legacy applications and protocols that we just don’t use in containers. So simplicity matters. How can we do better? Well, how about we build networks more like the internet? We know that works, at scale, and someone like Christopher can diagnose an internet backbone in 15 minutes.
- So, here’s a simplified view of what some corner of the Internet looks like
- And this is the Calico model. We push the router down onto each host.
- Here’s what the network looks like in Calico. Containers are connected to the root via a veth pair, which if you’re running Docker at all is in your Linux kernel. And then we just forward packets using Linux kernel routing. It’s been around for decades is fast, stable, and scalable. In fact, your containers are already using the Kernel IP stack---we just extend a little bit to forwarding decisions. We just insert local routes to local container IPs, and we learn over the BGP control protocol about containers on other hosts. BGP has a reputation for being complex, but actually it’s a really simple protocol at its core: a BGP message contains the IP destination, the next hop address, and some metadata to prevent routing loops. It is sometimes *used* in complicated situations, like Internet exchange points, but the data center is not complicated in that way. IP routing is flexible and powerful---it runs the global Internet. But it’s also very simple: there’s a single table, the routing table, that you use to look up where packets should go next. Operational simplicity leads has a lot of advantages. No encapsulation, no virtual bridges. If you monitor traffic in your physical fabric for security or QA you see the real container IP addresses and the real ports that your application is using. When you need to get traffic in or out of the cluster---it’s just IP routing! A few config tweaks to your border router and you’re good to go: no dealing with VXLAN on-ramps or anything like that. Your IT operations organization has been building and troubleshooting IP networks for years, and their standard diagnostics tools like ping and traceroute just work.
- Who can tell me what this graph is? It’s from Gordon Moore---co-founder of Intel---Gordon Moore’s seminal 1965 paper “Cramming more components into integrated circuits.” The origin of what’s known as Moore’s Law. Each of these curves shows how the price per transistor varies at different levels of scale in different years. The first thing to notice is that the sweet spot is moving EXPONENTIALLY over to the right, meaning we’re getting higher and higher density. But, I want to emphasize that it’s also moving down, so compute is getting exponentially cheaper too. <AWS graph> …and this is a real trend even today. This graph shows Amazons’ EC2 pricing. But what impact does this have on the network? Well, it’s getting more dense. Where, previously, a host had one IP address, the VM revolution brought 10 and now, with containers, we’re going towards 100 or more. At the same time, we’re moving our apps towards redundant, horizontally-scalable, autoscaled microservices, which place huge demands on the network in terms of number of endpoints and rate of churn.
- Here’s a video showing one of Calico’s routine scale tests. We’re running 500 hosts, and starting 50k containers and measuring time to first ping for every container.
- We now come to our final act, Act III: Attacks. Monday, November 24th, 2014. Just a little over a year ago, Sony Pictures Entertainment employees logged in to their computers in the morning and what they saw was this. I’m quoting Fortune.com here: “Before Sony’s IT staff could pull the plug, the hackers’ malware had leaped from machine to machine throughout the lot and across continents, wiping out half of Sony’s global network. It erased everything from 837 of its 1,555 servers.” The broader lesson from this story in “how.” How were the attackers able to cause so much destruction?
- Well, here’s how. This is a quote from FBI director James Comey, who investigated the attacks. Emphasis my own: “once the invaders made it past network gates they could go anywhere.” Sony Pictures built defenses along the perimeter of their network.
- I like to call this the armadillo model: crunchy on the outside, smooth on the inside.
- What happened to Sony is that after an initial penetration, the attackers used their largely unrestricted network against them. The initial site became a base of operations to launch additional attacks.
- And the way we’ve traditionally secured these sorts of applications closely mimics the application itself. Each tier is protected with a dedicated firewall, the idea being that each successive tier is harder to access, with your data tier being the hardest to access. Operations manages the firewalls, and developers manage the application.
- However, with the switch to micro-services, application architectures have gotten a bit more complicated. An application’s “tiers” are no longer monolithic programs. You’ve now got multiple distinct services comprising what historically has been considered a single tier. These micro-services each have their own distinct connectivity requirements. However, your network still looks like it has since the ‘90s. This makes it really hard to achieve progress, since operations still manages the firewalls while developers manage the application. If I want to add or remove services within a tier, I need to raise a ticket to have those firewall rules changed. If I want to add more isolation and security to my architecture, I need to add additional tiers. Both of these things are inhibitors to progress and innovation. And really, all you need to do is look to the number of big enterprise security breaches to see that this this “hard outer-shell, soft gooey center” security model doesn’t even work very well. All an attacker needs to do is compromise a single workload, and they get access to an entire tier of my application, or more.
- We could tear down all the walls. This means we don’t need to raise as many tickets when our application changes. This allows you to iterate on your application more quickly, but is less secure and less stable than before.
- So, consider a Kubernes cluster of n containers or pods, of the n-squared possible connections between all your containers, only a tiny, tiny fraction of them are useful for your application.
- Now, the cool thing about microservices is because they are so small and easily described, the developer knows exactly which services needs to be able talk to each other, and how. For example, I know that my database service responds to requests on TCP port 6379, and that my Go code needs to access my database. This is easily described in terms of developer intent, without requiring any nitty-gritty low-level networking concepts. If we could render this “developer intent” into network security, it would be a huge win. We can apply security policy directly attached to each micro-service, and we can do it automatically simply by looking at the developer’s intentions. No more dedicated firewall devices, no more crunchy on the outside soft on the inside, and no more tickets. So how can we get this developer intent feeding through to an operational reality?
- Front end load balancers don’t connect directly to the back end database. Your dev containers do not connect to prod, and every open connection path that doesn’t help run your application hurts your security. This is called the principle of least privilege.
- In Calico networking, we call this a distributed firewall. It operates pervasively inside the cluster, such that each and every container has its own firewall. We use iptables for this---every Linux host in your fleet is already capable of this per-container firewall, the challenge is of course how to manage it. In particular, you need a control function that directly integrates with your cluster manager so that dynamic events like scaling up or down don’t require any operator intervention. For Project Calico we’ve built plug-ins for Kubernetes, Mesos, and Docker Swarm for containers, and also OpenStack for VM workloads. And, of course, today I want to talk about Tectonic, which is Kubernetes based.
- I’m going to show you a demo of the new policy…
- Here’s the connectivity that we need
- But by default we’d have this
- Turning on isolation is a per-namespace flag
- OK, now everything is blocked.
- Lets add some policy to let the management UI talk to everything (but not the other way around)
- Cool, now the management UI can reach out
- Now lets allow the frontends to talk to the backends on a certain port. Note: we’re using a dynamic selector. If a new pod comes along with label tier=frontend, the firewall will adjust.
- OK, now this is the situation.
- Finally, let’s allow the client to talk to the frontends
- And this is what we have now. All the paths we didn’t want are blocked.
- I began this talk by reminding you that while the network used to be just the thing that you used to reach your customers, and now it has become a part of the application. Unfortunately we have seen an analogous change in attackers: it used to be the network was just how they got to your doorstep, not it’s an integral part of how attacks are carried out. So, get serious about network security, and remember that there are no neutral links---every network path is either helping run your application or just helping an attacker. So, I’d like to suggest to you the following characteristics as you consider the networking for your Tectonic cluster. Operational simplicity, scalability, and security---these are the things that make or break networks in the long run. And, therefore what we thought about as we designed Project Calico.