Introduction
Kubernetes applications are packaged, versioned, and deployed using Helm charts. They help deploy application services as well as Kubernetes components and utilities.
They facilitate internal and external scaling by bundling Kubernetes manifests and commands with pre-vetted default values. As a Helm user, you can install open-source packages known as charts.
However, our recent research discovered that over 70% of Helm charts in Artifact Hub featured misconfigurations that violated CIS Kubernetes Benchmarks, such as not setting resource restrictions and running root containers.
Table of Contents
What exactly are helm charts?
We should begin with a high-level exploration of how Helm charts to function.
Without Helm charts, you’d have to write numerous Kubernetes manifests (YAML files) to take an application, such as a container image, deploy it to your cluster, and handle the image’s additional parameters and how Kubernetes manages the container.
On the other hand, Helm bundles such manifests together, including dependencies such as monitoring tools, and includes a central location for default but customizable variables (values.yaml). If you’re familiar with Terraform, this is your vars.tf file.
Kubectl, like Helm install, will create and deploy Kubernetes manifests before deployment.
How does security in Kubernetes work?
Let’s begin our discussion of Kubernetes security with (what some might consider) the foundational layer of a Kubernetes environment: the host infrastructure.
In this context, we’re referring to the physical and/or virtual servers that act as Kubernetes nodes.
Making sure that each node, whether a worker or a master, is protected against security concerns is the first step in securing this infrastructure.
It is simple to use templates to provide each node with security best practices at the configuration and operating system levels.
When creating your IaC templates, ensure the startup script and/or image template for your nodes are set up to run only the programs strictly required to function as nodes. Libraries, packages, and unnecessary services should not be included.
A kernel-level security hardening framework like SELinux or AppArmor and fundamental hygiene practices like encrypting all associated storage may also be added to the provisioning of nodes.
Kubernetes cluster IAM security
You may utilize an external cloud provider to manage access restrictions for your Kubernetes environment, depending on where and how you operate Kubernetes.
For example, if you utilize AWS EKS, you will use AWS IAM to offer different levels of access to Kubernetes clusters based on the needs of particular users.
Using the least privilege approach to handle IAM roles and rules in IaC reduces the risk of manual setup errors that may allow too much access to the wrong user or service.
You can also utilize IaC scanning tools (such as Checkov, our open-source tool) to detect overly permissive or unneeded IAM roles and rules in your settings.
Security for container registries
Platforms for storing container images, known as container registries, are not built into Kubernetes.
However, they’re frequently used to host the images launched into a Kubernetes environment as a part of a pipeline for Kubernetes-based application deployment.
The access control frameworks used by container registries differ. Access can be managed by some registries (such as AWS ECR) using public cloud IAM frameworks.
In either case, access rights are often defined using code and then applied and managed using IaC.
You should do this while adhering to the concept of least privilege, which states that registered users should only have access to container images as necessary.
Equally crucially, it should be impossible for unauthorized individuals to upload photographs to a registry. Threat actors can efficiently distribute malicious images into your Kubernetes system using insecure registries.
Keeping away from the default namespace
This is a low-hanging fruit that is easy to overlook. Every Kubernetes cluster includes a namespace called “default” by default.
Unless you create other namespaces, workloads will be stored in the default namespace, as the name implies.
Although utilizing the default namespace isn’t the worst thing you can do, it does raise two security problems.
One advantage is that everyone will know the name of your namespace, which is a critical configuration parameter, making it easier for attackers to exploit your environment.
Again, this does not guarantee that you will be hacked simply because you use the default namespace, but the less information you give the wrong people, the better.
The other, more severe issue with default namespaces is that your workloads will not be segregated if everything runs there.
It is preferable to build various namespaces for different workloads. This makes it more difficult for a breach against a single job to grow into a cluster-wide problem.
Alternatively, you can use kubectl to create new namespaces or declare them in a YAML file. You may search existing YAML files for workloads configured to operate in the default namespace.
Avoid using privileged containers.
A vital security consideration at the container level is preventing containers from running in privileged mode.
This is simple to accomplish with IaC. Simply create a security context that limits access.
Again, IaC scanning tools can be used to check for the absence of this security context and any other privilege escalation settings within pod settings.
At the network level, isolate pods.
By default, any Kubernetes pod can communicate with any other pod via the network.
As a result, unless your pods genuinely need to communicate, you should isolate them to achieve greater workload segmentation.
You can create a network policy to isolate pods at the network level or to impose specific limitations on network connections between pods as long as your Kubernetes networking layer supports network policies (the majority do, but some Kubernetes distributions default to CNIs that lack this support).
Again, the advantage of expressing everything in code is that we can verify it for configuration errors or oversights that can unintentionally give more network access than we meant.
Investigate open-source components
No matter what version of the container image you use, you should never take security for granted. Helm’s charts also hold true to this.
Millions of publicly available container images and Helm charts have been found to have security flaws, some of which are very serious.
You should check for setup errors before utilizing any open-source Helm charts, whether they are from Artifact Hub or somewhere else.
Similarly, you should examine container images using tools before deploying them to find any vulnerable parts.
Although it isn’t quite IaC, this is comparable because it enables you to automatically identify security issues in Kubernetes before deploying them.
Turn on audit logging.
If a performance or security incident occurs, Kubernetes audit logs frequently assist with the investigation.
This is so that audit logs may track every action taken in response to a request sent to the Kubernetes API server.
Unfortunately, in most Kubernetes distributions, audit logs are not enabled by default. Add the following lines to your Kube-apiserver policy file to enable this feature:
–audit-log-path=/var/log/kubernetes/apiserver/audit.log
–audit-policy-file=/etc/kubernetes/audit-policies/policy.yaml
This instructs Kubernetes to locate the policy file that specifies what should be audited and where to store audit logs.
Including a rule in your Kubernetes configuration scans is critical to verify whether audit logs are enabled because they provide essential security information.
Conclusion
As you can see, Kubernetes is not very secure by default, and there is no “one method” that will solve all of your Kubernetes security issues.
Instead, Kubernetes security necessitates a multi-pronged approach that addresses the security vulnerabilities across Kubernetes’ multiple tiers.
Fortunately, by using an IaC-based approach to creating security rules in Kubernetes, you can make settings more quickly and reduce the chance of configuration errors that lead to security breaches at any layer of your Kubernetes stack.