Kubernetes Security: Steps to Secure Your Cluster
Kubernetes is designed to be configurable and extendable for various types of users and their use cases. It is not intended to be secure out of the box. Here's how to secure your Kubernetes cluster
A Penetration Tester friend once told me that a containerized environment is the easiest thing for him to hack. I could not argue with that much because I understood that in many cases, that would be correct.
Kubernetes, as a platform, is designed to be configurable and extendable for various types of users and their use cases. It is not intended to be secure out of the box. So if you are running your infrastructure on Kubernetes without paying attention to the platform's security, you are vulnerable to many attacks.
In today’s newsletter, we will talk about 7 (seven) ways you can tighten the security of your Kubernetes environment.
Before Deploying to Kubernetes Cluster:
Container Security: The first layer of security for a container orchestration platform is having secure containers. It is important to ensure that the containers you deploy into your Kubernetes environment do not introduce vulnerabilities to the cluster. Some things you can do to ensure secure containers include:
Do not use images from untrusted sources
Scan container images to verify their security before pushing them to your image repository
For your base images use leaner images with fewer tools preconfigured, for instance, alpine-linux
Scan images the images in your registry to ensure security
Run Containers as Non-Root Users and with Least Privilege Policy: One common way for attackers to exploit a Kubernetes cluster and cause damage is by gaining access to the host machine of the containers. This can be possible if an attacker gets into a container and can escalate privileges to execute commands to the host node. To avoid this, a container should not be run as the root as this would give any attacker that gets access to that container root privileges hence, the ability to cause serious damage
Security In Kubernetes Cluster:
Role-Based Access Control: This is a policy or strategy used to give users and services the authorization to perform only the necessary operations they need to perform within the cluster. A strong security strategy within almost any environment is to enforce least privilege access through authentication and authorization. RBAC enables Kubernetes Admins to do this. With RBAC, you can create users and authenticate them to the Kubernetes cluster using client certificates and then permit them to perform actions (view, create, update, destroy) using Roles(namespaced permissions) and ClusterRoles (cluster-wide permissions). Applications can also be granted permission using Service Accounts which are authenticated using tokens and assigned permissions using Roles and ClusterRoles.
Pod Communication Security: By design, in a Kubernetes cluster, all pods can communicate with each other. But in a more secure production environment, this should not be the case. We should only allow pods to communicate with pods that they need to be communicating with. For instance, a post running a database may not need to directly receive communication or traffic from a frontend pod. The communication policies can be enforced using NetworkPolicies which implement the policies on L3 (Network Layer) and L4 (Transport Layer) or you can enforce policies on L7 (application layer) using Service Mesh.
Etcd: Protect Your Crowned Jewel. In most Managed Cluster. Etcd is the data store within a Kubernetes cluster that contains all the data about the cluster. This is often referred to as the brain of the cluster and as such if corrupted, the entire cluster is corrupted. Since Etcd is a component of the control plane, in most cloud-managed clusters like GKE, EKS, and AKS, this would be managed by the cloud provider. However, in a self-managed cluster, Etcd needs to be kept as secure as possible. It should be highly available in a production cluster, it should be encrypted to prevent data leaking into the wrong hands and it should be backup for easy restore if compromised.
Security Policies: Many people would have access to a Kubernetes cluster including Developers (junior and senior), Kubernetes admins of various levels, and sometimes external customers. As a Kubernetes Admin, it is important to set policies on what can be done within a cluster and how it can be done correctly. Many people may not know the best practices for working in a cluster, so these policies would help guide them to do things correctly. Tools such as Open Policy Agent (OPA) and Kyvero can help Administrators implement Policy as Code.
Secret Management: Secret Objects in Kubernetes help you to encode your secret data. It does not encrypt it. This means that anyone who gets access to the secrets can simply decode the secret and have the plaintext value. It is important to use tools that can help encrypt and manage your secrets properly. I use Harshicorp Vault and would recommend that anyone, however, many third-party and cloud-managed tools can do this.
Implementing all or most of these steps would help harden your Kubernetes Cluster and keep you safe from attackers. However, this is not an exhaustive list and is only a foundational overview. it is important to implement these strategies even deeper to run a secure cluster.
Subscribe to this Newsletter to keep receiving easy-to-understand content on Kubernetes and DevOps Engineering
i am running a k8s environment, i want to use Vault for secret management. which will you recommend;
a. run vault on k8s
b. run vault on stand alone server and pull from it to k8s