A Guide to Kubernetes Security: Threats and Protections

Devashish Palkhe — Fri, 31 Jan 2025 07:00:13 +0000

Introduction

Kubernetes has revolutionized container orchestration, enabling organizations to deploy, scale, and manage applications seamlessly. However, with great flexibility comes great responsibility—securing a Kubernetes environment is no small task.

If you're already familiar with Kubernetes and want to delve deeper into its security aspects, this article is for you.

Security is a broad concept which is a combination of multiple things on multiple levels .It is not just 2-3 things which will protect your environment from attackers. Just one security link or a misconfiguration can open the door for attackers to breach your system.

Key Questions to Consider:

How can you prevent unauthorized access to your Kubernetes cluster?
What are the most common security misconfigurations that attackers exploit?
How can Role-Based Access Control (RBAC) help in securing your workloads?
What security tools and best practices can enhance your Kubernetes defenses?

In this guide, we’ll explore key threats to Kubernetes security and provide actionable strategies to harden your clusters against attacks. Let’s dive in! 🚀

Security best practices🎯

Enable Kubernetes Role-Based Access Control (RBAC)

Who can access the cluster ?
What permissions do they have?

This should be restricted as much as possible .

Assigning users specific privileges is a best practice in Kubernetes security. This is achieved through Role-Based Access Control (RBAC), which provides a standard method for managing authorisation where we define what user can perform. When implementing RBAC, it is recommended to use namespace-specific permissions rather than cluster-wide permissions to minimise risk. Even during debugging, avoid granting cluster administrator privileges, as excessive permissions can lead to security vulnerabilities.

Network policy

Kubernetes allows all pods within the cluster to communicate with each other which can make operation easier but also creates a security risks.

Communincation between pods is unencrypted this can lead to an attacker to read the communication in plain text .It is a good practise to limit communication by implementing network policy.

This can be done by using service mesh Istio.

It is a service mesh an open source app that injects as a sidecar container
It can handle network logic .
Acts as a proxy which ensured secure communication between services on a logic level.
We can also define rules.

Istio not not only provide configuration over networking but also can be used for tracing, metrics & security.

Misconfiguration of manifest

Misconfigurations are the most common source of security risk in containerized applications running on Kubernetes.

kube-linter a tool which checks your yaml manifests and also reports recommendations for resolving any potential issues and returns a non-zero exit code.

Some common issues that KubeLinter identifies are running containers as a non-root user, enforcing least privilege.

securityContext:
  readOnlyRootFilesystem: true
           runAsUser: 1000
           runAsGroup: 3000
           fsGroup: 2000

Securing Secret Data

Using secrets we only encode and store them in etcd and it is at risk when stored and can easily be decoded if accessed.K8s provides encryption by enabling EncryptionConfiguration but it is complex to set up and manage.We might need to store :

Credentials
Secret Token
Keys

This can be done by using Hashicorp Vault which store them by encrypting them and we can inject them in namespace by using External secret Operator.

Building secure Images

As we all know k8s is a platform where we run containerised applications using Images and creating such images is a core part of security .Basic image scanning is what everyone does but that alone is not sufficient .The best practises are:

Run as non-root user By default if we don't provide a user in Dockerfile it runs as a root user.Create a dedicated user and group and then change to non-root user with user directive .
Setting resource limits By default, a container has no resource constraints. It is great practise to set resource constraints for an image.
Keep secrets out Secrets, which include sensitive data such as credentials and keys, should not be embedded within container images.
Choose base images from trusted source All Dockerfiles start from a base image. Using trusted sources of image is important ,You can check for docker verified images .
Using multistage Docker build Multi-stage builds are useful to anyone who has struggled to optimize Dockerfiles while keeping them easy to read and maintain. With multi-stage builds, you use multiple FROM statements in your Dockerfile.

Secure the etcd

Etcd acts as a database for storing all cluster level information which continously monitors and updates the changes.It is a NoSQL ,key-value pair unencrypted .It stores manifests files for k8s resources.

If accessed by a hacker can add ,delete, update do any malpractice .

To secure the etcd we put etcd behind a firewall & allow only kube-api-server to access it with proper authentication.

Securing backup data

Application data needs to be backed-up and restore if any error occur or any downtime occurs and the data may have information such as :

Medical Record
Credit card info
Private information

To avoid any malpractice of such important data which can be leaked, altered or a ransomware we must secure it.

Kasten K10 at platform built for Kubernetes, provides enterprise operations teams an easy-to-use, scalable, and secure system for backup/restore, disaster recovery, and mobility of Kubernetes applications.

Configure Security policies

Admission Controllers are a crucial part of the Kubernetes security and governance framework. They act as gatekeepers, intercepting requests to the Kubernetes API server before they are persisted. When a request is made to the Kubernetes API server it's intercepted by the admission control layer.

Validating Requests: Ensure that incoming requests comply with predefined rules and policies.
Modifying Requests: Alter the requested objects before they are created or updated in the cluster.

Kyverno & Gatekeeper are widely used and popular due to their ease of use and powerful feature sets.

Bonus tips 💡

1.Keep the cluster up to date.

Patching Vulnerabilities: Updates often include critical security patches that address newly discovered vulnerabilities.
Improved Security Features: New Kubernetes versions may introduce enhanced security features, such as improved access control, encryption, or auditing capabilities.
Compliance: Staying up-to-date helps you meet compliance requirements and industry best practices for security.

2.Enhance app security

Secure applications exposed via Ingress controllers they provide IP whitelisting/blacklisting features.
Integrate a WAF with your Ingress controller. A WAF can inspect incoming traffic.

3.Limiting usage of resources via namespace:

Logical Separation: Namespaces provide a logical separation of resources within a Kubernetes cluster.
In case of back door entry and to prevent noisy neighbour we can set ResourceQuotas .

What we achieved

In this guide, we've explored critical security considerations for Kubernetes and provided practical strategies to strengthen your cluster's defenses. We covered a range of topics, including:

Granular access control (RBAC)
Network segmentation (Network Policies, Istio)
Secret management (HashiCorp Vault)
Etcd protection, secure backups (Kasten K10), policy enforcement (Kyverno, Gatekeeper), secure image building, and manifest validation (kube-linter).

Conclusion

Kubernetes security is a continuous effort its hard to secure 100% but implementing these practices will surely secure your environment. These best practices significantly improve your cluster's defenses. Stay informed about vulnerabilities and adapt your strategies.

Which practice are you most eager to implement? Share in the comments! The next blog post will provide step-by-step implementation guides for each topic. Follow us for updates!

A Quick Reference

Access Control: RBAC (built-in).

Networking: Network Policies (built-in), Istio (https://istio.io/).

Secrets: Vault (https://www.vaultproject.io/), External Secrets Operator (https://external-secrets.io/).

Manifests: kube-linter (https://docs.kubelinter.io/).

Images: Non-root, resource limits, no secrets, trusted base images (Docker Official Images: https://docs.docker.com/docker-hub/image-library/trusted-content/), multi-stage builds.
etcd: Access restriction, authentication, encryption.

Backups: Kasten K10 (https://docs.kasten.io/).

Policies: Kyverno (https://kyverno.io/), Gatekeeper (https://open-policy-agent.github.io/gatekeeper/).

DEV Community: Devashish Palkhe