Enhancing Security with Kubernetes: Best Practices

Before we dive into what a DevSecOps engineer would be responsible for in a Kubernetes cluster, let's consider Kubernetes from a security perspective to give some context. Kubernetes is, relatively speaking, new on the block. That is to say, it is an emerging technology. It's emerging but very popular, with many companies adopting Kubernetes, especially young tech and start-up companies.

Introducing any tool into a system is considered an increased security risk as a new tool means a new potential way into that system. These risks are amplified when dealing with a tool like Kubernetes, where you have a network of pods that can communicate with each other. The default setting allows any pod to communicate with another. This implies all kinds of security considerations. As a DevSecOps engineer, it is your responsibility to ensure these channels are secure.

• Kubernetes Hardening

  Container hardening is one way in which DevSecOps engineers can secure these channels, it the process of using container scanning tools to detect CVEs present in a cluster and remediate them to ensure minimal security breach risk.

  Kubernetes hardening is precisely that, ensuring these channels are secure by fortifying your cluster following best container security practices that you would perform as devsecops engineer. Various companies and government agencies have defined these best practices; let's go over each area in which we can strengthen our container security and how this can be done.

  Secure your Pods!

• Let's begin with a few ways to secure the pods themselves. Some best practices for pod security include:

  • Containers that run applications should not have root privileges

  • Containers should have an immutable filesystem, meaning they cannot be altered or added to (depending on the purpose of the container, this may not be possible)

  • Container images should be frequently scanned for vulnerabilities or misconfigurations

  • Privileged containers should be prevented

  • Pod Security Standard and Pod Security Admission

Hardening and Separation of your Network!

In the introduction to this task, one thing especially was flagged as a big security risk: communication. That communication happens over a network, and it's your job as a DevSecOps engineer to ensure this communication is secure. This can be done using the following best practices:

• Access to the control plane node should be restricted using a firewall and role-based access control in an isolated network

• Control plane components should communicate using Transport Layer Security (TLS) certificates

• An explicit deny policy should be created

• Credentials and sensitive information should not be stored as plain text in configuration files. Instead, they should be encrypted and in Kubernetes secrets

Using Authentication and Authorization Optimally

• It wouldn't be a security lesson if we didn't talk about authentication and authorization, of course! Kubernetes is no different. Here are some best practices which can help make sure you are making efficient use of Kubernetes authentication and authorization features:

  • Anonymous access should be disabled

  • Strong user authentication should be used

  • RBAC policies should be created for the various teams using the cluster and the service accounts utilized.

Keeping an Eye Out

• • Audit logging should be enabled

    • A log monitoring and alerting system should be implemented

Security Never Sleeps

This is in no way an endorsement of a sleepless lifestyle; DevSecOps engineers do, in fact, need to sleep! Being secure is one thing, staying secure is another. Here are some best practices to ensure your cluster stays a safe haven:

• Security patches and updates should be applied quickly

• Vulnerability scans and penetration tests should be done semi-regularly

• Any obsolete components in the cluster should be removed