Sep 5, 2023 | Kubernetes, Tutorials

Mastering Kubernetes with Cilium: Empowering L7 Traffic Control

by

With the new release of the Cilium CNI on our Kubernetes Service you’ll get the ability to filter traffic based on L7 properties. It’s very powerful and can help a lot with your services security.

In this tutorial, we’ll be securing an API endpoint to allow access only to specific routes by our client. All other traffic won’t even be forwarded to the service, thus keeping the load of the API as low as possible.

Prerequisites

Before you get started, you’ll need the following:

  1. A Kubernetes cluster up and running with Cilium.
  2. kubectl command-line tool installed and configured to communicate with your cluster.
  3. Basic knowledge of Kubernetes pods, services, and namespaces.

Creating API + API-Client

$ kubectl apply -f \
https://gist.github.com/modzilla99/0cbdd39cc838e752ae8cdb5ec3cdd03a/\
raw/adb7218bb1e9195c42192d71809f6f7043e50cd7/deploy.yaml
configmap/apiconfig created
deployment.apps/api created
service/api created
pod/api-client created

We’ve now created a service called “api” that is bound to the “api” deployment. It has two routes. The route /secret should be private and /greetings should be publicly accessible. Since we don’t have any NetworkPolcies defined, both routes are accessible by any pod running in the cluster.

Testing the API

So let’s try out the API first:

$ kubectl exec -it api-client -- curl -H 'X-Security-Header: mysecret' api/secret/mysecret
{
  "name": "mysecret",
  "secret": "syferghewg"
}
$ kubectl exec -it api-client -- curl api/greetings/World
Greetings, World!

$ kubectl exec -it api-client -- curl google.com
The document has moved

As you can see the API is fully accessible without any restrictions and the api-client pod has full access to the web.

Limiting Access

In order to minimize access, we aim to restrict the pods access exclusively to our api and api.github.com. The subsequent NetworkPolicy will effectively accomplish this goal:

 

---
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-client-egress
spec:
  endpointSelector:
    # Apply policy to api client
    matchLabels:
      app: client
      type: production
  ingress:
  # Drop all incoming traffic
  - {}
  egress:
  # Allow API acccess to GitHub only via HTTPs
  - toFQDNs:
    - matchName: api.github.com
    toPorts:
    - ports:
      - port: "443"
  # Allow access to our API
  - toEndpoints:
    - matchLabels:
        app: api
        type: production
    toPorts:
    - ports:
      - port: "6090"
        protocol: TCP
  # Allow DNS queries
  - toEndpoints:
    - matchLabels:
        io.kubernetes.pod.namespace: kube-system
        k8s-app: kube-dns
    toPorts:
    - ports:
      - port: "53"
    rules:
      dns:
      - matchPattern: "*"

Now the pod can only talk to our and the GitHub API as well as query the kubernetes DNS server. Any request to other resources will fail now:

$ kubectl exec -it api-client -- curl -4 --connect-timeout 3 -v google.com
* processing: google.com
* Trying 142.250.184.238:80...
* ipv4 connect timeout after 2974ms, move on!
* Failed to connect to google.com port 80 after 3001 ms: Timeout was reached
* Closing connection
curl: (28) Failed to connect to google.com port 80 after 3001 ms: Timeout was reached

$ kubectl exec -it api-client -- curl -4 https://api.github.com/user
{
  "message": "Requires authentication",
  "documentation_url": "https://docs.github.com/rest/users/users#get-the-authenticated-user"
}

Let’s secure secure our api next. We don’t want the pod to able to communicate externally and it should only allow ingress traffic to our two routes. Since the /greetings Endpoint is supposed to be public, we’ll open the access to anyone whilst restricting the access to the /secret Route to our api-client.

---
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-api-ingress
spec:
  endpointSelector:
    matchLabels:
      app: api
      type: production
  egress:
  # Deny any external traffic
  - {}
  ingress:
  # Allow access to /secret route from our api client 
  - fromEndpoints:
    - matchLabels:
        app: client
        type: production
    toPorts:
    - ports:
      - port: "6090"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/secret/.*"
          # Require HTTP header for authorization
          headers:
          - 'X-Security-Header: mysecret'
  # Allow access to /greetings route from anyone
  - toPorts:
    - ports:
      - port: "6090"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/greetings/.*"

Now we can only access the /secret route with the required header and from the api-client pod:

 

$ kubectl exec -it api-client -- curl api/secret/mysecret
Access denied

$ kubectl exec -it api-client -- curl -H 'X-Security-Header: mysecret' api/secret/mysecret
{
  "name": "mysecret",
  "secret": "adasge53whbetn"
}

Conclusion

Cilium NetworkPolicies are a powerful way to control network traffic within your cluster. By defining rules for ingress and egress traffic, you can secure your applications and isolate them as needed. This tutorial covered the basics of creating and using NetworkPolicies, but you can create more complex policies to suit your specific needs.

Need help with this topic? Feel free to send us a message or subscribe to our newsletter for more content on the topic.

Subcribe for next article

More articles in Kubernetes | Tutorials
LUKS Encrypted Storage on Kubernetes

LUKS Encrypted Storage on Kubernetes

More and more stateful workloads are making their way into production Kubernetes clusters these days. Thus, chances are that you're already using persistent volumes or persistent volume claims (PVs/PVCs) in lieu with your deployed workloads. If you want to thoroughly...

Comparing Kubernetes Deployment Tools – What We Got Today

Comparing Kubernetes Deployment Tools – What We Got Today

Imagine your company embraced a microservice architecture. As you develop and deploy more and more microservices, you decide to orchestrate them using Kubernetes. You start writing YAML manifests and additional configuration, and deploy necessary tooling to your...

Introducing the NWS Kubernetes Playground

Introducing the NWS Kubernetes Playground

We are thrilled to introduce our brand-new NWS Kubernetes Playground! This interactive platform is designed to help you master cloud-native technologies, build confidence with tools like Kubernetes, and explore a range of NWS offerings – All for free!   What is...

LUKS Encrypted Storage on OpenStack

LUKS Encrypted Storage on OpenStack

Thoroughly securing your IT landscape has become more and more important over the last couple of years. With an increase in (user) data to be managed, processed, and stored, encryption of this data should be on your agenda towards fully secured IT infrastructure....

Securing ingress-nginx with cert-manager

Securing ingress-nginx with cert-manager

In one of our first tutorials, we showed you how to get started with ingress-nginx on your Kubernetes cluster. As a next step, we will tell you how to go about securing ingress-nginx with cert-manager by creating TLS certificates for your services! What is...

Migrating Servers from VMware to Openstack

Migrating Servers from VMware to Openstack

In this tutorial, we will have a look at migrating servers from VMware to OpenStack. After VMware's recent acquisition by Broadcom, many Cloud Service Providers (CSPs) face termination of their partnership programs with VMware. With no further information publicly...

Upgrading Ubuntu: From 20.04 to 22.04 with Nextcloud 26 and PHP 8.1

Upgrading Ubuntu: From 20.04 to 22.04 with Nextcloud 26 and PHP 8.1

Every couple of years Ubuntu brings out a new LTS version of its operating system and with it comes a bundle of new applications and dependencies. This can be both exciting and challenging for sys-admins who need to make everything work after an upgrade. One of the...

Using Terraform with OpenStack

Using Terraform with OpenStack

Many of you may already be familiar using Terraform with Azure or AWS. Although these may be the most used platforms, there is still a need for variety of other options due to local regulations (GDPR). As our systems are geared towards Open-Source, we will be looking...

Dynamic Inventory – An Ansible and Openstack Lovestory

Dynamic Inventory – An Ansible and Openstack Lovestory

For those of you that may not be too familiar with Ansible, it is a great tool to get started in the world of automation and making your life with configuration management a whole lot easier. In this tutorial we will be going through a basic playbook that you can use...

ReadWriteMany (RWX) with the NFS Ganesha Provisioner

ReadWriteMany (RWX) with the NFS Ganesha Provisioner

Introduction You have the desire that your application needs to scale across multiple nodes for load balancing, but needs access to a common PVC? For this purpose, you need a PVC that is RWX-enabled. As part of our Managed Kubernetes Cluster, it is possible to create...