Khaled Taha Portfolio

January 15, 2025

Cluster Setup

Securing your Kubernetes cluster is a foundational step in keeping your applications safe. As Kubernetes environments grow more complex, ensuring the security of your cluster becomes just as important as…

Securing your Kubernetes cluster is a foundational step in keeping your applications safe. As Kubernetes environments grow more complex, ensuring the security of your cluster becomes just as important as deploying your applications effectively.

In this guide, we’ll explore the process of setting up a Kubernetes cluster with a strong emphasis on security best practices. From choosing the right tools to implementing configurations that protect your cluster, this walkthrough will equip you with the knowledge needed to build a secure and robust Kubernetes environment tailored to your needs.

Network Policies

Network policies are an essential Kubernetes resource for securing your applications and preventing abnormal behaviors. By default, all applications in a Kubernetes cluster are allowed to communicate with each other. Now, imagine an attacker gains access to a pod in your cluster—without network policies in place, the attacker could communicate with all your applications and even intercept connections between services. This is where network policies become crucial.

With network policies, you can define which services an application can communicate with using pod resource labels.

Key Concepts
spec.podSelector.matchLabels: Used to select the pods that the network policy will apply to.

Policy Types:
Ingress: Controls incoming traffic to the pod.
Egress: Controls outgoing traffic from the application.

For more details, you can check the official Kubernetes documentation on network policies.

Advanced Scenarios

Kubernetes network policies work based on labels. However, if your use case requires more complex scenarios—such as blocking specific ports, IP ranges, or implementing layer 3, 4, or 7 policies—you’ll need to use an external CNI like Cilium. Cilium introduces a new CRD (Custom Resource Definition) that extends functionality across multiple network layers. For more information, refer to Cilium’s documentation.

By effectively working with these policies, you can control communications between your services by explicitly allowing or denying them, enhancing the security of your Kubernetes cluster.

CIS benchmark

CIS Benchmark is the product of a community consensus process and consists of secure configuration guidelines developed for Kubernetes.

The use of this tool is straightforward. Simply run the command and specify the node type as either a master or worker node. The tool will then scan your node’s configuration and generate a detailed report outlining the necessary modifications to comply with the CIS guidelines.

Set up Ingress with TLS

Ingress TLS is an important security layer for securing external communications. However, it is not natively handled by the default CNI plugins. CNI plugins like Flannel, Calico, or Weave focus on networking and pod-to-pod communication, but they don’t manage TLS termination for external traffic. To enable Ingress TLS, you need to install an Ingress Controller (e.g., NGINX, Traefik) and configure it to handle TLS encryption for inbound traffic.

Verify platform binaries before deploying

Verifying binaries before installing is an important step because the binary could be modified, and installing a modified binary could cause malicious behavior on your server, potentially leading to unauthorized access to your environment.

Verifying binaries is a straightforward step. You can use tools like sha256sum or sha512sum to check the integrity of the binary by comparing the result with the hash provided by the binary source.

2 Comments

January 15, 2025

Sewar

It is very clear and useful to read!

Does checking the binaries process(in practice) happen in the CI/CD pipelines automatically or manually?
Also, Does this process occur in the hosting device or inside the cluster itself?

Reply
    January 15, 2025

    admin

    Checking the binaries can vary depending on the case. Where should the binary be used?
    If it is inside a Dockerfile and will be installed with each build, the verification should occur within the Dockerfile.
    If the binary is a tool installed on a server and only installed once, the verification will be a manual check.
    The process takes place on either the hosting device or the pipeline agent.

    Reply

Leave a Reply