Introducing The New “Kubernetes Networking and Cilium for the Network Engineer” eBook!

A book for network engineers by a network engineer

1st February 2005. That’s when my career in network engineering started and where I’ve mostly operated ever since.

I started in network support, fixing issues on standard enterprise networking technologies, but I quickly had to learn and adapt: wireless networking, Data Center networking, MPLS, Service Provider routing, etc. In the 2010s, I turned to software-defined networking, cloud networking, and network automation.

Working in tech for over two decades has taught me to re-invent myself constantly. I am not claiming to have excelled at all technologies (I still remember the pain of failing a certification exam because of my lack of deep understanding of MPLS), but I wasn’t afraid to get outside my comfort zone.

That is until I met my nemesis.

A technology that looked utterly unapproachable and just too complex for my simple networking mind to compute. The word itself began to invoke dread.

Kubernetes.

No matter how hard I tried — reading documentation and watching video tutorials — I couldn’t get my head around it. Let’s face it — most content about Kubernetes has not been written for network engineers like me. Even worse, the Kubernetes Networking terminology is so drastically different from traditional networking that it confuses even experienced network practitioners.

Maybe you feel the same way. Maybe you’re amongst the network engineers who find themselves intimidated by Kubernetes. Or maybe you’re just curious about Kubernetes and Cilium because of the recent news about Cisco acquiring Isovalent.

In any case, learning Kubernetes has never been as relevant and we wanted to give something back to the networking community and help folks overcome the challenges I faced.

So here is the eBook I wish I had 5 years ago – written by a network engineer for network engineers, this eBook is like an instruction manual focused on Kubernetes Networking and the de facto Kubernetes networking layer, Cilium.

Even if you’re not a network engineer, we hope you find the eBook accessible and easy to follow, even if some of the references to traditional networking might pass you by.

Table of Content

Here is what the 56-page eBook covers:

• 🔧 What We Need The Network To Do
• 🔗 Kubernetes Networking Fundamentals
• 🔹 Introducing Cilium
• 💻 Where is my CLI?
• ⚙️ How do I configure Kubernetes and Cilium?
• 🖧 Where is my DHCP Server?
• 🔍 What is a Kubernetes namespace?
• 🔎 Where is my DNS Server?
• 🔍 How Do Pods Talk To Each Other?
• 🔍 Kubernetes Metadata
• 🏷️ What’s a Label?
• 📝 What’s an Annotation?
• 🔒 How do I secure my cluster?
• 🔐 What’s identity-based security?
• 🔥 Where’s my Layer 7 firewall?
• 🔥 Where’s my Load Balancer?
• 🔄 How do I load balance traffic within the cluster?
• 🔄 How do I load balance traffic entering the cluster?
• 🌐 Where’s my web proxy?
• 🔌 How can I connect my cluster to existing networks?
• 🔌 I don’t have any BGP-capable device in my existing network. Is there another way for me to access my Kubernetes services?
• 🔐 How do I connect my cluster with an external firewall?
• 🔐 How do internal Load Balancing and NAT work under the hood?
• 🔍 How do I manage and troubleshoot my network?
• 🔍 How can I monitor and visualize network traffic?
• 🔒 How do I start securing my cluster?
• 🔐 How do I encrypt the traffic in my cluster?
• 🔄 How do we connect clusters together?
• 🌐 Is IPv6 supported on Kubernetes?
• 📊 Does the concept of Quality of Service (QoS) exist in Kubernetes?
• 🔌 Which Kubernetes networking options are available in managed Kubernetes services?

Head over to the download page by clicking on the button below.

If you’d like to read an excerpt before downloading it, read on below.

Final Words

Some of you may think 56 pages are too long and too in-depth. I apologize: the original concept was just to publish a 5-page glossary to correlate Kubernetes networking terminology with the traditional networking space. I just found the topic was too complicated to be that succinct.

Some of you may think the eBook is too short. It was actually much longer initially, but we decided to make some editing decisions and cut out the chapters on service mesh, multicast, and multi-networking. If the feedback on this first edition is positive, nothing stops us from publishing an even more complete second edition or a follow-up volume.

In any case, we greatly welcome your feedback and comments. Feel free to contact us on social media to share your thoughts. You can find me on LinkedIn at @nicolasvibert.

Excerpt

How do I secure my cluster?

As you can imagine, Kubernetes Security is very complex and covers multiple areas such as data encryption at rest and in transit, protection of the control plane and workloads, auditing, Identity and Access Management – the list goes on. Some highly recommended books have been published and dedicated to Kubernetes Security. Let’s focus on one aspect of security you would probably be interested in and answer the question:

What is the equivalent of firewall rules in Kubernetes?

The answer is Network Policies.

Kubernetes Network Policies are implemented by the network plugin/CNI. Not all CNIs support network policies; some provide more advanced and granular network policies than most (we will review the benefits of using Cilium Network Policies shortly).

Standard Kubernetes Network Policies let you specify how a pod can communicate with various entities. They rely on Layer 3 and 4 elements and let you filter based on IP addresses or ports/protocols (such as TCP:80 for HTTP or TCP:22 for SSH).

Kubernetes Network Policies are implemented by the network plugin/CNI. Not all CNIs support network policies; some provide more advanced and granular network policies than most (we will review shortly the benefits of using Cilium Network Policies).

Standard Kubernetes Network Policies let you specify how a pod can communicate with various entities.

It’s based on Layer 3 and Layer 4 elements – you can typically filter based on IP addresses or ports/protocols (such as TCP:80 for HTTP or TCP:22 for SSH).

We’ll now review a sample Network Policy.

It should look familiar to most network engineers, but you might find some configuration aspects new.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

In the networking world, you would be familiar with an extended Access List (ACL) for example:

!
interface ethernet0
 ip access-group 102 in
!
access-list 102 deny tcp any any eq 23
access-list 102 permit ip any any

It denies all TCP traffic over port 23 (Telnet) and allows anything else. Note that the ACL applies to traffic entering (in) the Ethernet0 interface – in other words, it’s our selector: we select the traffic to which this particular filter applies.

In Network Policies, we use a podSelector to determine who the filters will apply to. An empty one would select all the pods in the namespace. A standard method is to use labels to identify the pods the policy applies to.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
spec:
  podSelector:
    matchLabels:
      role: db

In the ACL example above, we used the keyword in to indicate the rules would apply to traffic entering the interface. In Kubernetes Network Policies, we would use the ingress block:

ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24

Consider the example above – you can see how we are allowing traffic from the 172.17.0.0/16 block, with the exception of 172.17.1.0/24 range.

In a Cisco ACL, the equivalent would be something like this:

ip access-list extended K8s_Net_Policy
  permit ip 172.17.0.0 0.0.255.255 any
  deny ip 172.17.1.0 0.0.0.255 any
  permit ip any any

But we can also combine it with selectors – we can allow traffic only it comes from particular blocks, from a specific namespace, and from a specific pod:

ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend

Why would we do this when IP addresses were all we needed in Cisco IOS ACL? As mentioned earlier, IP addresses are primarily irrelevant in Kubernetes. Pods are started and destroyed frequently. One of the advantages of Kubernetes is its ability to scale up and down an application by creating or deleting multiple replicas of a pod across the cluster. The IP addresses of pods are unpredictable.

Traditional IP-based firewalling approaches are going to be mostly ineffective.

What’s identity-based security?

Cilium’s Network Policies are an advanced method to secure clusters. For the reasons highlighted above, Cilium’s approach to security is not based on IP addresses but on identities. Identities are derived from labels and are assigned to endpoints (Cilium refers to Kubernetes pods as endpoints).

Instead of creating a rule allowing traffic from the frontend pod’s IP address to the backend pod’s IP address, you would create a rule to allow an endpoint with the label role=frontend to connect to any endpoint with the label role=backend.

Whenever replica pods are created with such labels, the network policy will automatically apply to such pods, meaning you will not have to update the existing network policy with the IP addresses of the new pods.

Another benefit provided by Cilium Network Policies is Layer 7 filtering.

Where’s my Layer 7 firewall?

Cilium Network Policies also provide Layer 7 application visibility and control. Y ou will be familiar with this concept if you use any web application firewalls (WAFs). Cilium Network Policies let you filter based on application (Layer 7) parameters, like HTTP path, method, or domain names.

Let’s review an example:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "rule1"
spec:
  description: "L7 policy to restrict access to specific HTTP call"
  endpointSelector:
    matchLabels:
      org: empire
      class: deathstar
  ingress:
  - fromEndpoints:
    - matchLabels:
        org: empire
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: "POST"
          path: "/v1/request-landing"

While Kubernetes Network Policies used podSelector, Cilium Network Policies use endpointSelector to determine which endpoints this applies to. The principle remains the same – the policy above will only apply to pods with the labels org: empire and class: deathstar.

The policy will only permit HTTP traffic from pods with the org: empire label with the HTTP POST method and to the path /v1/request-landing.

Note that, while the CiliumNetworkPolicies offer advanced Layer 7 capabilities, they do not replace a web-facing firewall or an advanced IDS/IPS. You will learn in a later section how to integrate Kubernetes with your firewalls.